cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject Re: [RT] reconsidering pipeline semantics
Date Fri, 05 Jul 2002 21:58:00 GMT
Stefano Mazzocchi wrote:
> I personally don't like the document() function of XSLT. I normally
> suggest to use an xinclude stage to perform aggregation when the
> structure of the aggregation is not fixed, but that's really up to you.
I personally don't like Cocoon aggregation, basically
because it is proprietary to Cocoon, while document()
is a mandatory feature of all XSLT processors.

Well each of the three aggregation methods has its
Cocoon aggregation: controlled by sitemap, non-intrusive
  to XML and XSLT
xinclude: controlled by XML source
document(): controlled by stylesheet writer, non-intrusive
  to XML

The downsides of of document() are that it is not quite
compatible yet with Cocoon caching, and many people have
difficulties to understand the two argument form and how
relative URIs are resolved.

>>In any case, aggregation seems not to be quite right.
> Why? what's the problem you are experiencing?
I have a bunch of XML files with the same DTD. They
could be processed with the same XSLT and mapped by
the same pipeline if I use document(). If I use
aggregation, I'd have to use a separate pipeline and
XSLT (because of the new document element and skipping
the aggregated content until it's needed) for the
currently two sources which need aggregated content.
Using an aggregation pipeline for all documents seems
to be a bit of an overkill, especially because the
directories read are on mounted drives which are slow
on occasion.
Using xinclude doesn't change the picture much, instead
of an aggregating pipeline I'd have to use a three stage
pipeline (transformation of reference to xinclude,
xinclude, final transformation), the only advantage
being that XML content can be used for constructing
the referencing URLs (which will probably be needed).
With document(), I can put a <news from=".."> element
in any source and get the content for aggregation where
and when it is needed, no need keep track which source
uses news in order to get it into the correct pipeline.
The other advantage is that I can develop the XSLT
locally using a standard XSLT processor, thereby getting
short turn around times. The other variants require
a Cocoon running somewhere, and in my experience this
slows down the edit-test-cycle even if I edit the XSLT
in place, mainly because I always need to reload the
page in the browser, and problems must be looked up in
the logs.


To unsubscribe, e-mail:
For additional commands, email:

View raw message