cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] reconsidering pipeline semantics
Date Sat, 06 Jul 2002 09:50:31 GMT
"J.Pietschmann" wrote:
> 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.

Hmmm, sounds like a physolophical point only to me, unless you really
want to use your xslt stuff in other pipeline systems (AxKit, for
example), but I never heard of anybody having that requirement.

> Well each of the three aggregation methods has its
> place:
> 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.

document() was designed when xinclude with xpointer facilities wasn't
there. I bet that if xinclude existed before, they would not have added
this feature to xslt 

NOTE: document() is not defined in the XPath language because they
thought that didn't really fit there. document() is an XSLT extension to
XPath that mimics xinclude + xpointer.

Today, they cannot deprecate it because there is no way to describe the
a multistaged pipeline execution of an xml document, thus there is no
way to specify that document() behaves like xinclude:include

But for Cocoon we have that way so the only reason why I would use
document() for external aggregation (or external entities, which are
even worse) is when I have to move the XSLT in some pipeline engine
which is not xinclude-capable and where I don't have a predefined way to
indicate the steps of the document processing.

> >>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.

In that case I agree: like I said, if you need to do your stuff without
Cocoon around, or without a precise way (xpipe?) to define how a
document is processed, document() is the way to go. That's the only
argument I acknowledge.

For the rest of the arguments, I simply disagree: inclusion and
transformations are two different concerns, but, like I said before,
it's really up to you to use the one you like the most.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message