Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
From: "Ricardo Rocha" <ricardo@apache.org>
To: <cocoon-dev@xml.apache.org>
Subject: RE: XSP (minus Cocoon plus SAX) success story
Date: Thu, 27 Jan 2000 14:59:22 -0800
Message-ID: <NDBBJIOLGLAOBAAGJJIMOEDLCOAA.ricardo@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <Pine.LNX.4.10.10001271726510.25236-100000@phoenix.webslingerZ.com>
Importance: Normal

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!

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!

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.

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.

The 2 syntaxes DO NOT overlap in regard to dynamic
node creation.

The fact that both <xsp:element> and <xsl:element> yield
a comparable end result does not mean their semantics
are the same.

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.

Ricardo