You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steve Muench <sm...@us.oracle.com> on 2000/01/24 21:19:08 UTC
Re: XSLT/XSP Unification?
Scott,
I share your confusion and have been dropping
hints on the cocoon list off and on about
how these could come together. I'm hoping
it's just timing that's made the two stay
apart. Reading through the XSP docs and
finding tags like:
<xsp:expr>
<xsp:element>
<xsp:attribute>
<xsp:comment>
that mimic the <xsl:XXX> equivalents
made me wonder even more why these mechanisms
don't just find a happy marriage: XSP as a library
of extension elements. I know not every XSLT
processor has yet implemented extension elements
yet, so perhaps this was a consideration given
the timeframe.
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 benefits of having a built-in include
mechanism, and a set of core "actions" that
increasingly XML-savvy web developers are
becoming familiar with is compelling.
My gut feeling tells me that a unification
would deliver the benefits of both,
allowing people to use the core XSL actions for
the most basic things and smoothly transition
to <xsp:xxx> or <xyz:xxx> actions to handle
additional "vocabularies" of functionality
without having to wonder whether <xyz:element>
was the same thing as <xsl:element>.
While JSP is not generally talked about much
on this list, the JSP Tag Library mechanism
in JSP 1.1 seems to be trying to accomplish
the same kind of *core* + extension libs
idea around the JSP technology stack. XSLT Extension
elements seem like the natural XSL-way to do
the same thing.
Just my humble opinion...
_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: "Scott Boag/CAM/Lotus" <Sc...@lotus.com>
To: <Co...@xml.apache.org>
Cc: <xa...@xml.apache.org>
Sent: Monday, January 24, 2000 10:56 AM
Subject: XSLT/XSP Unification?
| Well, I hope I don't ruffle any feathers with this one, or start a flame
| war. This is an attempt to explore the possibilities of XSLT and XSP
being
| unified within Cocoon. I'm probably off the mark a little bit here... I
| don't totally understand the XSP model, and haven't had time to go into it
| as deeply as I should. But I wanted to get my thoughts out while the game
| is still early. I suspect there have already been some conversations
along
| these lines that missed me or that I was not privy to.
|
| First, looking at XSP, it appears on one level to be doing something very
| similar to XSLT. On another level, it appears to be doing stuff that
might
| improve the use of XSLT in batch environments.
|
| My assertions are:
|
| 1) The two technologies seem to unnecessarily overlap. This cause
| unneeded complexity and learning curve, and a burden for users who have to
| understand subtle differences between xsp:pi, xsp:include, namespace
| handling, whitespace handling, extensions, etc., and the XSLT
counterparts.
|
| 2) The two technologies ought to be combined: xsp as a namespace of the
| xslt transform. Given "Literal Result Element as Stylesheet", I don't
| think you would loose anything in terms of simplicity. XSP would be made
| stronger by use of XSLT features, and XSLT would be made stronger by use
of
| XSP features (I'm thinking primarily of using xsp:logic, xsp:expr, etc. as
| an extension mechanism within Xalan).
|
| 3) I need help on Xalan: the kind of resources that are being used in XSP.
| For instance, we badly need to build and refine the extension
architecture.
| I note that XSP docs say they are thinking of using BSF, which Xalan
| already does. The XSP "Util classes" are mostly perfectly appropriate for
| use in XSLT extensions. It would be nice to work towards compiled
| stylesheet architecture, which is related to the work that is being done
on
| XSP (I think) etc. etc. etc.
|
| Note that the possibility exists here to work on a standard extension
| architecture that can be rolled back into the W3C.
|
| 4) I need to understand better XSP vs. XML-syntax for JSP... but, in any
| case, what a confusing picture... JSP is justified because it is a stream
| model with generic data input... for certain types of jobs, JSP syntax is
a
| better choice. On the other hand, while the same can be said of XSP, it
| seems to be an extra shade in between JSP and XSLT.
|
| 5) There is also the subject of the SQL processor, which is heavily
related
| to all this. I would love to see the SQL stuff being set for XSP, be
| available for use in XSLT.
|
| 6) I don't think performance is an issue here. A XSLT/XSP combo can
| perform just as well as raw XSP, and maybe better, given more focus.
|
| 7) I understand the need for simplicity in XSP. But, I think if we worked
| closely together, we could come up with something close to being as
simple,
| that is a far more powerful sum of the parts.
|
| Comments? If I'm way off mark, I'll just go sulk back to my cave...
|
| -scott
|
|
|
|
Re: XSLT/XSP Unification?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSLT/XSP Unification?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSLT/XSP Unification?
Posted by Steve Muench <sm...@us.oracle.com>.
| 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" <st...@apache.org>
To: <co...@xml.apache.org>
Cc: <xa...@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.
| <st...@apache.org> Friedrich Nietzsche
| --------------------------------------------------------------------
| Come to the first official Apache Software Foundation Conference!
| ------------------------- http://ApacheCon.Com ---------------------
|
|
Re: XSLT/XSP Unification?
Posted by Steve Muench <sm...@us.oracle.com>.
| 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" <st...@apache.org>
To: <co...@xml.apache.org>
Cc: <xa...@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.
| <st...@apache.org> Friedrich Nietzsche
| --------------------------------------------------------------------
| Come to the first official Apache Software Foundation Conference!
| ------------------------- http://ApacheCon.Com ---------------------
|
|
Re: XSLT/XSP Unification?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XSLT/XSP Unification?
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------