cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: XSLT/XSP Unification?
Date Tue, 25 Jan 2000 19:24:17 GMT

Stefano Mazzocchi <stefano@apache.org> wrote:
> 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).

The "literal result element as stylesheet" (LRES) has nothing to do with
content generation vs. transformation.  It is a simplified pull-only
stylesheet.  XSLT does two things: "pull" data from the source tree into a
template, and have the nodes be "pushed" onto it so it can match a template
to the given node.  These are not two models, but a single transformation
model that uses two different tools.  ASP/JSP/XSP/LRES-XSLT are all
transformations of the source data, no matter how you look at 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

As I said in a previous note, XSLT can do the same thing as XSP, as proved
by SAXON.  Personally I think that page compilation is a red herring... it
is the last stage of an optimization process, and will only get in the way
of performance if other optimizations are not correctly made, but that is
beside the point of this discussion.

> 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.

I don't think so at all.  The LRES was an effort to layer the language so
that "simple things could be done simply".  The need for extensions can't
be worked around.  The use of extensions to generate dynamic content is an
obvious part of the model.  If you don't think dynamic content creation
should not occur as part of the transformation process, I think it should.
But the point is, XSLT can be used in both application models.... it is a
general language for general uses.

> True, we can forget about XSP and use the
> standalone-XSLT-with-extentions, but man, no matter what:

I don't think either Steve or I are proposing to forget about XSP.   The
positive response to it on the list shows how valuable it is, and I'm
certainly not one to argue with user response.  What I think we are saying
is that XSP should use XSLT, and the two should combine forces to make a
more powerful mechanism.

> I don't like
> it and it will never be so portable and fast as our solution.

Given that you can keep the existing XSP codebase and make some minor
language changes to make XSP compatible with XSLT, I can't agree with your
assertion.  What I am asking in the near term is: make minor changes in the
XSP syntax so that XSP can be fed through the Xalan processor (and
eventually other processors as the extension mechanism becomes
standardized).

-scott




                                                                                         
                         
                    Stefano                                                              
                         
                    Mazzocchi            To:     Cocoon <cocoon-dev@xml.apache.org>
                               
                    <stefano@apac        cc:     xalan-dev@xml.apache.org, (bcc: Scott
Boag/CAM/Lotus)             
                    he.org>              Subject:     Re: XSLT/XSP Unification?       
                            
                                                                                         
                         
                    01/25/00                                                             
                         
                    07:47 AM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         




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
files.

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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------







Mime
View raw message