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 Mon, 24 Jan 2000 23:02:30 GMT
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

porting this to the XML world leads to

  xml -> transformer -> xml

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

 xml -> transformer -> xsp -> producer -> xml

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:

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

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

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

View raw message