cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XSLT/XSP Unification?
Date Tue, 25 Jan 2000 12:47:10 GMT
Steve Muench wrote:
> | while for XSP, the <util:count> tags is seen by the
> | content writer as the magic tag that is magically
> | transforms itself into the right number, for e-XSLT,
> | that tag is a trigger for some template that includes
> | the magic tag.
> I don't see how <util:count> is any more or less magic
> than <xsl:value-of select="Something"/>. It's a known
> action that the user expects to have an effect in the
> resulting page.

Good point.
> | The difference is minimal, but very important: both
> | programmers and page writers are are used to linear
> | flow, learning XSL requires substantial
> | skills that we do not want to impose on people.
> With the E-XSLT approach, users could have it either way.
> They can achieve the linear thing they are familiar
> with using the "simple stylesheet":
>  <page xmlns="urn:xyz" xmlns:util="urn:util"
>         xsl:extension-element-prefixes="util">
>   <content>
>    <p>You've accessed this <util:count type="user"> times</p>
>   </content>
>  </page>
> This is equivalent to just having a single match="/"
> root template (without having to mention template anywhere
> for the novice). The "literal result element as
> stylesheet" feature in XSLT was put in to allow users who
> don't want to take the full template approach to not have
> to understand it when they don't need it's power.

True, but I still think XSLT covers up too much ground it should have
delegated to other specifications. Content generation has very little to
do with transformation and use different parts of your brain (at least
my brain).
> So, while you *do* need the template approach for a Stylebook
> or DocBook kind of stylesheet, you do not need it for
> a linear page that's assembling the "data/content" to be styled
> using extension elements from multiple producers.

I see clearly the equivalent of "XSP with taglibs" and "standalone-XSLT
with extentions". They are interchangeable, this is true.

> Invoking a compiled XSP "action tag" and invoking an
> XSLT extension element implemented in compiled Java
> code are really pretty similar. Maybe the only difference
> is what code is doing the invoking. In the former, it's
> the compiled code of the XSP Page Processor, in the
> latter it's the compiled code of the XSLT Processor.

Well, this will create a substantial performance difference on big

Think about it:

for E-XSLT you have to: 

 1) parse the page
 2) scan thru it
 3) execute the XSLT instructions (if present)
 4) execute the extended tags (if present)

for compiled XSP you have to

 1) call the compiled page

So you save:

 1) parsing stage (already precompiled)
 2) string generation stage (you can compile the page using chars[] and
pass them directly to the SAX handler without going to the String
creation phase)
 3) XSLT interpretation (already precompiled)

the only thing you have to do is what you can't possibly do before
request time: dynamic content generation.

The use of standalone-XSLT with extentions for such a thing, is, IMO, a
total dirty hack and I was very surprised to see something dirty like
that introduced inside the spec.

True, we can forget about XSP and use the
standalone-XSLT-with-extentions, but man, no matter what: I don't like
it and it will never be so portable and fast as our solution.

> There may need to be tweaks and "precisazioni" (refinements?)
> made to XSLT's extension mechanism to handle this kind
> of unification, but in principle and spirit the
> two aren't far off.

No, the spirit is the same, but instead of enlarging XSLT to make it do
everything, there are other "ad-hoc" solutions that might work better.

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