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