This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
xsl:script considered dangerous -- Re: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: xsl:script considered dangerous -- Re: [xsl] XSLT 1.1 comments
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Tue, 13 Feb 2001 14:20:47 -0500 (EST)
- cc: xsl-editors at w3 dot org
- Reply-To: xsl-list at lists dot mulberrytech dot com
I concur with Uche that xsl:script is a poor addition to XSLT.
I can only say one "positive" thing about xsl:script, it is
far less verbose than XSLT proper. However, XSLT's verbosity
can be addressed by introducing a new namespace, "xf" with
the following behavior:
Anywhere, except as a child of "xsl:template",
<xf:func x="y" /> is equivalent to <xsl:call-template name="func">
<xsl:with-param name="x"
select="y" />
</xsl:call-template>
and when a child of xsl:template,
<xf:func x="y"> is equivalent to <xsl:template name="func">
... <xsl:param name="x"
</xf:func> select="y" />
...
</xsl:template>
I wrote a stylesheet that did a bi-directional conversion
between these two syntaxes about a year ago. And it is
very pretty. No need for xsl:script. Keep it simple.
Other than that, I respectfully include by reference
all of Uche's wonderful comments. Please take his remarks
for action.
Respcts, Clark Evans
On Mon, 12 Feb 2001, Uche Ogbuji wrote:
> The first problem I see with xsl:script is the human engineering aspect.
> XSLT 1.0 had extensions but had the admirable quality that extensions
> were opaque to XSLT itself. This encourages people using XSLT to have
> the XSLT mind-set and learn how to solve problems within the
> language. At some point they might come across a situation that needs
> extensions, but puuting this in place was a separate operation with
> their stylesheet processor which set up an *environment* for the opaque
> extensions within XSLT itself. I think this healthy layering is a good
> part of the reason why there has been so much advancement of the state
> of XSLT practice in just one year: it was quite clear how to layer
> one's thinking between XSLT and extension. With xsl:script, the
> layers are muddies, and I think it will lead people (who, after all
> often search for expedient over good sense) to jump in with extensions
> without mind to the inevitable interoperability problems.
..
> "The implementation of the extension functions identifies the local names of
> the functions that is is implementing."
>
> Python's dynamicism means that these implementing functions can change.
> Is it the statically defined or current dynamic function set that is
> used to map the local names?
>
> BTW, why are the language names other than the Sanctified Three
> specified as Qnames? What is this supposed to look like?
>
> {http://microsoft.com}VisualBasic ???
>
> Why is this necessary?
>
> "When a function implementation is provided locally in the content of the
> xsl:script element, the src attribute must not be specified."
>
> This language means that a stronger statement has to be made than
>
> "XSLT processors are not required to support any particular language binding.
> xsl:script elements with language values not supported by the processor are
> ignored."
>
> It should also point out that the processor need not check any conformance
> constraints made with regard to xsl:script elements in an unsupported
> language binding. Basically, that "ignore" is not clear as to whether
> it refers to structure or processing.
>
> It is also unclear as to how xsl:script interacts with fallback. If there is
> a script element and my processor does not not support it and there is a
> fallback for that element, can I ignore the fallback and use a separately
> registered extension module for that namespace URI?
>
> All of this complication would be reduced if language bindings were left to
> additional layers on XSLT as appropriate.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list