Subject: xsl:script considered dangerous -- Re: [xsl] XSLT 1.1 comments From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx> Date: Tue, 13 Feb 2001 14:20:47 -0500 (EST) |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments, Elliotte Rusty Harol | Thread | Re: [xsl] XSLT 1.1 comments, Alexey Gokhberg |
Re: [xsl] XSLT 1.1 comments, Francis Norton | Date | Re: [xsl] XSLT 1.1 comments, Scott_Boag |
Month |