cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: XSP (minus Cocoon plus SAX) success story
Date Fri, 28 Jan 2000 12:00:52 GMT
Ricardo Rocha wrote:
> 
> Stefano Mazzocchi wrote:
> > I find myself in the strange situation where XSP is something in between
> > JSP and E-XSLT....
> > . . .
> > That's how I feel XSP right now: a little squeezed between two big guys
> > :)
> 
> Hmmm, unfortunately I've been so _incredibly_ busy these
> days I haven't had the time it takes to write a well thought out
> post about this. Damn it!

No problem (Ricardo is leaving the US for visa problems... and hopefully
end up living in Italy near my house.... talking about Exoffice stealing
friends :)

> I'll try to present one of the main points now before all of
> us end up losing our religion:
> 
> XSP Layer 1 is a *code-generation* vocabulary. E-XSLT is
> part of a transformation vocabulary.
> 
> This is a critical distinction!

Totally!!!!! 
 
> XSP Layer 1 is a code generation vocabulary aimed at
> producing DOM transformation code. As such, it can be
> used to generate server pages (as it does now) or to
> generate E-XSLT extension handlers.
> 
> Being a DOM transformation language, XSLT provides
> means of dynamically building nodes. When you say:
> 
>   <xsl:element name="continuous-function">
> 
> you're saying "insert an element called 'continuous-function'
> at the current result tree position"
> 
> In XSP Layer 1 (being a code-generation, server page
> vocabulary) when you say:
> 
>   <xsp:element name="continuous-frunction">
> 
> you're actually saying "insert executable code to create
> an element called 'continuous-function' at the current
> source program position".
> 
> These 2 are _not_ the same! Dynamic node building tags
> in XSLT and XSP cannot be unified.

yes yes yes yes yes yes

> Let's assume we're using XSP's code generation facilities
> to generate *XSLT extension handlers.* (a perfectly
> legitimate usage, as XSP doesn't dictate the final "rendition"
> of the generated source program as a servlet, a Cocoon
> producer or, yes, an XSLT extension handler).
> 
> Think carefully: what would we use in this case? <xsl:element>
> or <xsp:element>?
> 
> Are you done thinking? You see? XSP Layer 1 defines its
> own namespace, so it comes naturally a beast like
> <xsp:element> rightfully exists.

Yes, while I agreed that XSP should not define any better model of
transformation/generation since EXSLT provides that, I don't have a clue
on _how_ the two "interpretation/compilation" modes of operation can
coexists.

Probably, an extended tag will have two logicsheets: one for
interpretation, one for compilation. Great would be the ability to use
one for both, but it's probably impossible even if they share the same
logic. Hmmm... or maybe not... hmmm...
 
> The 2 syntaxes DO NOT overlap in regard to dynamic
> node creation.

No, they don't and will never do.
 
> The fact that both <xsp:element> and <xsl:element> yield
> a comparable end result does not mean their semantics
> are the same.

Totally well put.
 
> There's much more to this. I just wanted to present one
> of the key facts. As long as we (wrongfully) look at XSP
> as a plain transformation language we'll end up perceiving
> it as redundant in regard to E-XSLT. As soon as we introduce
> the code-generation factor, our function becomes clearer.

That's the key issue: if EXSLT is used to "interpret" the extended tags
into generated "content", this is nothing new from the normal EXSLT
perspective. If EXSLT is used to "generate code that, if executed,
results in the same content that would have been generated after the
interpretation level" that's another story.

The distinction should be clear now and forever, but it's not a design
problem, rather an implementation problem. That was, again, my wrong
assumption.

On the other hand, Scott once said that XSP and EXSLT were not different
ideas converging, but rather XSP a subset of the EXSLT ideas.

He is right from a design perspective, he's not from an implementation
perspective.

That's why I'm happy :)

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