Re: XSLT 1.1 comments

> | and alternatively:
> | 
> | -> if two conforming XSLT 1.1 processor implementations both
> |    have elected to implement the C++ language for extension
> |    functions, then developers can expect that ...
> |        Really, what can we expect in this case?
> 
> At a minimum, they can expect exactly what they can
> expect in XSLT 1.0, that is, nothing.
> 
> Doing better than that, XSLT 1.1 provides an extensible
> <xsl:script> mechanism for vendors to cooperate to agree
> on a common C++ language binding, with a common QName
> that describes the binding and which can be used in
> the <xsl:script language="QName"> construct.

XSLT 1.0 already provided this cafility: with extension functions and 
elements.  If people need to band together to standardize exceptions, they can 
do so without xsl:script.  I still haven't heard from you why this isn't so.

> If the vendors do *not* want to cooperate to come up with
> a C++ specific binding that they share, then they are
> in the same situation as with XSLT 1.0.
> 
> Net net, XSLT 1.1 neither promotes nor hinders this from happening,
> but it provides a new mechanism to make it possible, should it
> be the will of the web community.

My point is that I see no technical advantages that XSLT 1.1 has added.  
Everything it provides for could be done at proper layers using XSLT 1.0.  
However, I do see 2 big non-technical disadvantages.

1.  It encourages people to write non-interoperable stylesheets (by 
introducingxsl:script)

2.  It gives a political boost to implementors of Java-based XSLT 
implementations (by writing language bindings into the language and allowing 
Java as a first-class extension language specification)

What do the Java folks gain by making this clearly controversial addition?  If 
they need a conveneient URI for their extension namespaces, I'm sure something 
can be easily worked out.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list