cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Pipeline Symmetry and XQuery, XSLT2.0. etc.
Date Mon, 30 Dec 2002 04:05:00 GMT
What you'll find below is my *personal* view of things and allow me to 
remind to everybody that I count as *one* like anybody else on this 
project so these do not (nor could!) represent the vision of the entire 
Cocoon development communities.

Jason Foster wrote:
> This might not be totally relevant to the current discussion of pipeline 
> symmetry, but I leave that decision to those more familiar with the 
> abstractions that I.
> I have recently been looking at the specifications for XQuery, XPath 
> 2.0, and XSLT 2.0.  A few things jumped out at me that seem relevant to 
> Cocoon.  In particular:
> - almost every example in XQuery uses the document() function
>     - those XQuery examples that don't use document() use input()
>     - some XQuery examples work on multiple documents simultaneously
> - XSLT will be supporting output to multiple documents from multiple 
> input documents
> The problems that I see arriving soon are:
> - caching becomes really problematic (IIRC the situation with document() )
> - Cocoon is seen as "unfairly" restricting which XSLT/XQuery constructs 
> are allowed (e.g. only a single input/output)
> I realize that the Cocoon community is already busy figuring out the 
> components and goals of version 2.1.  My concern is that to maintain a 
> reputation as an amazing XML processing system, Cocoon will need to 
> incorporate things like XQuery and XSLT 2.0 sooner rather than later.  
> These new technologies will likely impact on pipelines, caching, and 
> other core aspects of Cocoon.
> Is it worth worrying about these issues now, or are they 3.0 material?

It is always worth worrying about new things, but only if they are kept 
in context.

Let me answer your points separately:

1) XQuery uses document() extensively.

When I say that I don't like "document()" I mean that I don't like the 
fact that XSLT mixes concerns between transformation and aggregation. 
IMHO, XSLT should focus on transforming an infoset that it receives, 
without having any other dependency rather than on the stylesheet itself.

This eases caching in pipeline contexts and keeps things separate (which 
is good for pipeline debugging purposes!).

The use of document() in XQuery is totally different.

XQuery *must* operate on different documents in order to be useful, but 
I picture that it will be some other software to run the XQuery against 
a dataset (in my architectural dreams, XIndice or Slide with an XIndice 
store underneath) and I picture it would be totally silly to run an 
XQuery over a dynamically generated dataset like if you had to use 
document(cocoon://whatever) in your XQuery.

It will be up to the content repository to run the query and behave 
nicely in respect of document() so I don't think there is a Cocoon issue 

2) XSLT will be supporting output to multiple documents from multiple
input documents

This is admittedly a problem architecturally wise, but XSLT has already 
features that Cocoon totally ignores. For example, <xsl:output> which is 
totally wrong in a Cocoon context since it's the sitemap (and not the 
stylesheet) that should drive the serialization.

I would suggest to keep ignoring all those XSLT features that don't make 
sense in a more complex XML-processing environment like ours.

Stefano Mazzocchi                               <>

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

View raw message