"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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
