xsl:script considered dangerous -- Re: XSLT 1.1 commen

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