cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Happy to be wrong!
Date Thu, 27 Jan 2000 23:33:15 GMT
Have you ever been happy to be wrong? 

Of course, not always, but sometimes it feels good to see something that
you were missing before and understanding that doing this you saved lots
of pain and wasted resources.

Federico and I went to dinner out tonight and we came to the conclusion
than the XSP specification can be _totally_ represented as an
Extended-XSLT taglib. Nothing of what I've previously said is true: you
gain nothing by using XSP.

The problem I had was driven by the "stylesheet compilation" idea. I'll
will explain shortly why I think this is misleading and I will also
explain this in a moment.

As you all know, the XSP idea came after seeing lots of holes in JSP
support for XML. This doesn't go away. JSP cannot be used inside Cocoon
and this won't change soon.

Ok, let's move on: this is the XSP model how I imagined it

 XML -XSLT-> XSP -something-> Java -javac-> Class -execution-> XML

Ricardo added something and this is how it's done today

 XML -XSLT-taglibs-> XSP -XSLT-> java -javac-> producer -execution-> XML

Many proposed the use of E-XSLT to do the same thing... my concerns
where due mainly to performance reasons but they went away... let's
see... you suggest to do something like this


as you see, there is a topological equivalence between the two, being
the XSP model, a way to express how an E-XSLT engine should work
internally. This was not clear when I designed XSP since it was Ricardo
that added the namespace-taglib driven idea to the XSP spec. This
completely changed the picture.

The only concern I had, was still performance: how can EXSLT work faster
than a compiled server page? simple, it can't.

Scott proposed stylesheet compilation as a solution: but in my mind I
could not see how compiling a stylesheet would help... true, you could
simplify many things and do faster transformations but you still had to
do XML parsing, events feeding, tree creation and evaluation and a bunch
of stuff...

Tonight, Federico opened my eyes (man, I'll miss that guy! these
exoffice mean men are stealing all my friends, damn it! :)

A smart E-XSLT engine should _not_ perform stylesheet compilation (which
may be helpful but no that much), but do _page_ compilation. Let's look

 XML -EXSLT-> Java -javac-> producer -execution-> XML

so, if we evaluate the two with what Cocoon does today we get

 -EXSLT-> := -XSLT-taglibs-> XSP -XSLT->

which makes XSP totally useless since it's just a step between XSLT

QED :)

NOTE: I still like the ability to use XSP as a taglib for direct code
inclusion inside a page, it may be helpful.

Anyway, I'll happily let Ricardo and all you other XSLT experts figure
out the way to make the above possible, but I've been finally convinced
and I'm a happy guy now :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message