cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conal Tuohy" <>
Subject RE: FAQ and snippet, document() function
Date Tue, 09 Jul 2002 22:04:04 GMT
Don't be too quick to deprecate document()!

I think it is very important to fix Cocoon so that it can support
document(), for two reasons:

1) It's necessary for reusing code from non-pipeline-based systems. I don't
know of many people migrating XSLT from Cocoon to non-pipeline systems, but
the other way is common, and for these people (me included), it's important
to be able to reuse such legacy code in Cocoon, BEFORE refactoring it to
properly separate concerns. Otherwise we're imposing a barrier to entry
which is undesirable.

2) The point about SoC is valid, for sure, but I think there is still a
place for document() to be used properly in Cocoon. A small "inclusion" XSLT
using document() could be used in place of xinclude, and in fact there are
some circumstances where it is more suitable than xinclude or Cocoon
aggregation. It seems to me that the point is  not that inclusion should
only be performed by the xinclude, cinclude, or aggregation components, but
that it should be performed as a distinct stage in a pipeline. So I think
document() shouldn't be written off entirely, but instead users should be
encouraged to treat "inclusion" separately from other concerns, even when
the inclusion is performed by an XSLT using the document() function (in
fact, especially then, since xinclude is always a separate step, by
definition, while it's POSSIBLE to mix inclusion with other concerns in a
single XSLT.)



> -----Original Message-----
> From: Diana Shannon []
> Sent: Wednesday, 10 July 2002 03:15
> To:
> Cc:
> Subject: FAQ and snippet, document() function
> Appropriate use of the document() function in Cocoon
> represents one of
> the
> major conceptual FAQs among XSLT users migrating to Cocoon. Recent
> discussions
> on cocoon-dev and cocoon-users have shed a lot of light on
> the subject.
> Below is a draft FAQ, based on Stefano and Jan's recent dicussions on
> cocoon-dev.
> Within it you will also find a pointer to a proposed snippet ( Conal
> Tuohy's recent
> post on cocoon-users) which provides an xinclude-based alternative to
> the document() function.
> Please help to review both and comment here (or cocoon-users) as
> necessary.
> -- Diana
> Q. What's "wrong" with use of the document() function in Cocoon?
> A. Using the document() function for aggregation in Cocoon breaks
> Separation of Concerns (SoC). That is, the designers of Cocoon
> view inclusion and transformation as different functions, best
> handled by separate Cocoon components. Treating them
> separately allows you to achieve performance gains and increases
> the resusability of your pipelines.
> Alternatives to the document() in the Cocoon environment include
> aggregation or the use of a multi-stage transformation using the
> XInclude Transformer. This involves transforming a list of documents
> (generated dynamically or statically) by adding xinclude
> elements which
> reference (via xpointer) specific document content, and then
> transforming
> again via the XInclude Transformer, to obtain the desired result.
> For an example of this, see:
>   (Proposed Snippet)
> You'll achieve better performance if you aggregate content prior to
> transformation.
> This allows you to take full advantage of Cocoon's pipeline
> caching. In
> contrast,
> making dynamic document() calls inside an XSLT within a
> cached pipeline
> is problematic.
> At this time, Cocoon does not recognize changes in documents
> (called by
> the document() function)
> until the requested page expires from cache.
> Understand that the document() function was designed *before* xinclude
> with xpointer facilities existed. Had such capabilities been
> available,
> perhaps the document() function, which essentially mimics
> xinclude and
> xpointer,
> would have never been added to XSLT.
> Please note that if you must work with your XML files outside of the
> Cocoon environment as well, you may need to use the
> document() function
> in order to utilize the limited capabilities of other
> pipeline engines.
> This includes engines which are not xinclude-capable or which
> lack a predefined way to indicate document processing steps.

View raw message