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 01:05:00 GMT

Stefano Mazzocchi  wrote:
>> The biggest concern I've heard from implementors
>> as I promote this idea is "but then we'd
>> have to run *twice* through the XSLProcessor
>> to process a page: once to produce the "data"
>> and once to "style it". And my answer is, "So?"
>
>:)
>
>The whole point can be placed in that very vocal "so?"

Depending on what you want to do, producing the data for transformation and
the styling process can all be combined into a single transformation.  You
could even do things like produce a data transform, and then statically
combine it with the style transform to produce a single transform.  My
major point here is, if they share the same base, there are more options.

>  Both you and Scott partecipated in the development of XSLT and I see can
> clearly see why you want to push for unification.

I have had this same argument in relation to JSPs, and come out on the
other side of the fence, due to careful consideration of the use cases.  I
really think this is not "our technology vs. your technology".  I believe
both of us could benefit from a unification.

In any case, Steve M. and I have been deeply involved with XSLT, and might
have a good perspective on the features of the language to see how XSLT can
work in the scenarios you describe.

> I thought about this many times and I still cannot think that XSLT and
> XSP are the same thing.

I don't think all of XSP==XSLT, but I think parts do, and the rest of XSP
could be implemented within a good XSLT extension mechanism, giving the
best of both worlds, without sacrificing the simplicity of XSP.

> They are slowly converging, this is true, as it
> happens when good ideas meet and get in synch.

No, it's more than both being good ideas.  XSP is implemented within the
constraints of XML, is producing XML, is transforming a data source via a
template (classic "pull" stylesheet), and implements an extension
mechanism.  These are all things that XSLT does.

> The XSP model is more operationally complex, but more intuitive for
> users:
>
>  xml -> transformer -> xsp -> producer -> xml
>              ^
>              |
>          logicsheet

This seems like simply a more elaborate transformation model.  I don't see
why the choice of transformation language effects this diagram.

> 1) performance: the XSP page is compiled, no need for request-time
> transformation (not true with stylesheet compilation: even if compiled,
> the transformation processed _must_ take place!)

I don't see why the use of XSLT in the "XSP" step of your model affects
this.  Can you elaborate?

> <page>
>  <content>
>   <p>This page has been called <util:count type="user"> times by you</p>
>  </content>
> </page>
>
> 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.

Not at all.  In XSLT util:count can easily be an extension that magically
transforms itself into the right number too.  I don't see a difference in
the semantic language models.

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

You can present XSLT with XSP extensions exactly (or nearly exactly) the
same.  You can even still call it XSP, if you want.  When they need the
power, the can step into it as they need the advanced push/pull model.  The
only complication would be the requirement for two namespaces, and even
that could probably be hidden from the user if we put our minds to it.

> Like many already noted, mixing code with XML and XSLT is a real pain in
> the ass. A nightmare for some people.

I don't understand this.  XSP is XML also, right?  (I could very well be
missing something here).  I notice that the examples in the XSP page have
to deal with things like the less-than character: &lt;.  Again; I simply
don't see a big difference in the language models, and so don't understand
why you see such a gulf.

> Of course, being you heavily XSLT focused, you fail to see the problems
> in learning it, but I see a need for XSP,

Believe me, I get this rubbed into my face everyday.  But the complexities
in XSLT are there for a reason... they have to do with XML and the nature
of transformations in general.  Ultimately, I believe this will/must be
solved with tools.  In the meantime, XSLT is layered... you only have to
use what you need.

> although I don't have problems
> to combine efforts so that the same taglibs may be used for JSP, XSP and
> E-XSLT.

Well, this at least would be a major step, and would address part of my
concern.

Stefano, I don't pretend to understand the whole of the model you are
outlining (at least for me, it isn't totally intuitive).  But, so far, I
still don't see a big gulf in terms of language syntax and semantics.  I
really think we should try to come up with a strawman unification to see
what it would look like.  Software/design reuse isn't always easy, but it
often pays in the end.

-scott




                                                                                         
                         
                    Stefano                                                              
                         
                    Mazzocchi            To:     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/24/00                                                             
                         
                    06:02 PM                                                             
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         




Steve Muench wrote:

> The biggest concern I've heard from implementors
> as I promote this idea is "but then we'd
> have to run *twice* through the XSLProcessor
> to process a page: once to produce the "data"
> and once to "style it". And my answer is, "So?"

:)

The whole point can be placed in that very vocal "so?"

Both you and Scott partecipated in the development of XSLT and I see can
clearly see why you want to push for unification.

On the other hand, Ricardo and I were not and this maybe the issue why
we see different approaches.

I thought about this many times and I still cannot think that XSLT and
XSP are the same thing. They are slowly converging, this is true, as it
happens when good ideas meet and get in synch.

I will start providing you with a general idea: this is what I call the
"T model", may be viewed as a special turing machine.

  input -> function -> output
              ^
              |
         instructions

porting this to the XML world leads to

  xml -> transformer -> xml
              ^
              |
             xslt

the xslt extention idea is simple: allow extentions to XSLT instructions
to make the transformation language turing complete.

While this is great for very complex operations (like SVG graph
generation out of a database table, or even VRML generation of an XML
document into a room) it has a substantial limitation: lack of context
separation between content generation and content transformation.

True, content transformation _is_ content generation, but they require
different skills.

The XSP model is more operationally complex, but more intuitive for
users:

 xml -> transformer -> xsp -> producer -> xml
             ^
             |
         logicsheet

the benefits are:

1) performance: the XSP page is compiled, no need for request-time
transformation (not true with stylesheet compilation: even if compiled,
the transformation processed _must_ take place!)
2) visible result: the XSP page is a result of the transformation. In
fact, there is no difference if the XSP page was hand generated, or
generated thru logicsheet transformations. This results in a better
separation of contexts, while in extended-XSLT, operational tags are
always mixed with xsl tags.

NOTE on 2): while this difference may not be obvious, let's come up with
an example:

<page>
 <content>
  <p>This page has been called <util:count type="user"> times by you</p>
 </content>
</page>

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.

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.

So, while our XSP tags are the magic one (we create, design, write and
control the standard logicsheets), to do extended XSLT, you must write
your stylesheets and add the magic tag there. A step people will like to
avoid since many will be scared by flow-less template-driven approach.

Like many already noted, mixing code with XML and XSLT is a real pain in
the ass. A nightmare for some people.

XSP allow you to _totally_ forget about that. E-XSLT, allow to forget
about mixing code with XML, but they don't remove XSLT from the way and
this is our goal.

Of course, being you heavily XSLT focused, you fail to see the problems
in learning it, but I see a need for XSP, although I don't have problems
to combine efforts so that the same taglibs may be used for JSP, XSP and
E-XSLT.

But, of course, I'd be happy to be proven wrong on this unification.

What do others think? Ricardo? Donald?

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