cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Muench" <smue...@us.oracle.com>
Subject Re: XSLT/XSP Unification?
Date Tue, 25 Jan 2000 00:38:31 GMT
| 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.

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

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.

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. 

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. 

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team

----- Original Message ----- 
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Cc: <xalan-dev@xml.apache.org>
Sent: Monday, January 24, 2000 3:02 PM
Subject: Re: XSLT/XSP Unification?


| 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