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.It is always worth worrying about new things, but only if they are kept in context.
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?
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 there.
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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
