Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Mon, 12 Feb 2001 17:56:56 -0700
> | 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 

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.                
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python

 XSL-List info and archive:

Current Thread