Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <39B10CCA.1E48ADB3@apache.org>
Date: Sat, 02 Sep 2000 16:20:58 +0200
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: C2 XSP SQL taglib
References: <Pine.LNX.4.21.0009011326330.3906-100000@ma7.webslingerz.com>
 <39B03BB5.D354A1FE@apache.org> <39B040F5.B679836E@apache.org>
 <006101c0147b$c774fe00$72164498@us.oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steve Muench wrote:
> 
> Ricardo, Stefano,
> 
> | We may also consider XSLT's own use of <xsl:element> where attribute
> | name can take a dynamic XPath expression:
> |
> |   <xsl:element name="{@tagname}">...</xsl:element>
> |
> | Since XSP doesn't support XSLT's {...} idiom inside attributes, we
> | may need to do something like...
> 
> Did you guys give up on the idea of thinking of XSP's
> as simple-form XSLT stylesheets that use the XSLT extension
> element mechanism? The archives are down at the moment or
> I would have dug up the mail trail from months ago where
> I thought Stefano had come around to this way of thinking...

Yes, I did change my mind on the subject but I still believe that XSLT
should _not_ have simple-form XSLT stylesheets. It's a hack, big time
hack.

> Whenever it seems that there's a need to invent a facility
> already provided by XSLT, then this idea pops back to the top
> of my head.

Oh, totally.

There is clear overlapping between XSP and XSLT and XSLT 1.1 extentions
might end up being _very_ similar to what Ricardo proposed with his
SiLLy language.

Now the question: do we _really_ want to add server pages capabilities
to XSLT?

I've asked Sharon to tell me why XSLT is still called XSLT and not XTL
or something equivalent but nothing about styling... and she said that
it's to avoid turning XSLT into a general language for
transformations...

(which already is, BTW, and almost everybody knows that styling has
nothing to do with semantic transformations, despite DSSSL friends
advocate the opposite)

but then you want to add portable, language abstracted, extentions and
even enforce to _remove_ the notion of transformation with the
simple-form model hack that moves from "transformation" to direct
"generation"... 

I'm sorry, but I don't like this and I don't care if we have to include
90% of the XSLT elements into XSP or even invent some more... XSLT
simply is NOT designed for what we want to achieve for language
abstracted XML generation. Period.

BTW, if a technology that is called "eXtensible Stylesheet Language for
Transformations" is able to "generate" non-styled XML content without
performing any transformation, this should tell you something.

And the fact that the XSL WG doesn't even seem to care about this,
doesn't clearly advocate for its use in "real" open environments when we
can avoid it.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------