Some thoughts on Cocoon

[Alain Ketterlin <al...@dpt-info.u-strasbg.fr>]

Hi all,

I was just browsing through some docs, and the following raised some
questions I would like to ask to the list. This is all very
speculative, and I may be completely wrong. Please let me know if this
is the case.

First, XSLT 1.1 (http://www.w3.org/TR/xslt11/) throws away
"result-tree-fragments", and what they represented becomes "real"
nodesets. Am I right in thinking that this change will eliminate the
need for stylesheet-chaining? (and thus simplify the pipeline, since
everything can be done in one stylesheet). Anyway, both XT and Xalan
(>2.0 I think) already have some sort of
result-tree-fragment-to-node-set (extension) function. So why have
successive stylesheets when one can do all the work?

Second, XSLT 1.1 and Xalan2 seem to go quite far in integrating
extension elements/functions (Xalan2 even has an SQL extension
library). XSLT will soon allow "External objects"
(http://www.w3.org/TR/xslt11/#external-objects). Can this be seen as a
possible (partial) replacement for XSP (i.e. replacing taglibs with
extension libraries)?

If you are an active Cocoon user, and have some time to loose (:-) I
would like to have your opinion on these remarks, and on their
potential impact on Cocoon's architecture (if any).

-- Alain.

Re: Some thoughts on Cocoon

[Donald Ball <ba...@webslingerZ.com>]

On Mon, 22 Jan 2001, Alain Ketterlin wrote:

>
> Hi all,
>
> I was just browsing through some docs, and the following raised some
> questions I would like to ask to the list. This is all very
> speculative, and I may be completely wrong. Please let me know if this
> is the case.
>
> First, XSLT 1.1 (http://www.w3.org/TR/xslt11/) throws away
> "result-tree-fragments", and what they represented becomes "real"
> nodesets. Am I right in thinking that this change will eliminate the
> need for stylesheet-chaining? (and thus simplify the pipeline, since
> everything can be done in one stylesheet). Anyway, both XT and Xalan
> (>2.0 I think) already have some sort of
> result-tree-fragment-to-node-set (extension) function. So why have
> successive stylesheets when one can do all the work?

maybe. it's unknown which solution actually works well in the real world.
applying successive stylesheets which operate on well-defined doctypes may
be easier to maintain.

> Second, XSLT 1.1 and Xalan2 seem to go quite far in integrating
> extension elements/functions (Xalan2 even has an SQL extension
> library). XSLT will soon allow "External objects"
> (http://www.w3.org/TR/xslt11/#external-objects). Can this be seen as a
> possible (partial) replacement for XSP (i.e. replacing taglibs with
> extension libraries)?

possibly, but xslt-1.1 isn't here yet. it should be noted that the xsp
engine could be re-implemented to generate xalan extension functions
instead of cocoon processor-type classes without too much difficulty.

- donald