Re: [xsl] XSLT 1.1 comments

[Daniel Veillard <Daniel.Veillard@xxxxxxx>]

On Sat, Feb 10, 2001 at 06:18:04PM -0700, Uche Ogbuji wrote:
> This is just one of the manifestations of language-centric thinking that has 
> unfortunately crept into the XSLT 1.1 spec.  This concept might seem 
> attractive to people working in Java, C++ or Python.  But it is by no means 
> universally applicable.  I also don't see its use.
> 
> In the xsl:script section, please drop the "ecmascript" | "javascript" | 
> "java" nonsense from the "language" attribute specification.  This just 
> inflames those of us who worry about the W3C's language bias.  Popularity is 
> not even a good excuse, since VB is probably a more popular scripting language 
> for XSLT extensions than Java.  It's also totally unnecessary.

  Too late I'm afraid. It has been locked in through the requirements
section for XSLT 1.1 :-( :

  http://www.w3.org/TR/xslt11req#section-Requirements-for-Portable-Extension-Function-Implementations

----------
3 Requirements for Portable Extension Function Implementations
- Language bindings MUST be provided for Java and ECMAScript
- A processor SHOULD NOT be required to implement the portable extension function binding for any particular language 
----------

  As you can see the extension was deemed more important than the
portability, and this totally in opposition to what seems the main
point raised in the introduction:

----------
"The XSLT user community has consistently voiced the opinion that the non-portability of stylesheets is a key problem."
"The primary goal of the XSLT 1.1 specification is to improve stylesheet portability."
----------

unfortunately the way they suggest to achieve this is by defining mapping
for targetted language.

It seems they didn't considered restricting themselves to a clear cut 
of function needing a formal definition and sticking to it.

----------
"This goal will be achieved by standardizing the mechanism for
implementing extension functions, and by including into the core XSLT
specification two of the built-in extensions that many existing vendors
XSLT processors have added due to user demand:[...]"
----------

> 
> In general, I think the re-introduction of xml:script is execrable.  XSLT 1.0 
> had perhaps the most elegant extension model possible, and xsl:script ruins 
> this by destroying the opacity of extensions to XSLT processors.  Language 
> bindings may make sense in the realm of CORBA or DOM, where the actual 
> expression of the program is done in the bound language, but XSLT is XSLT, and 
> introducing the need for language bindings only reduces general 
> interoperability while giving a small boost to interoperability between small 
> axes of implementations.  In fact, I get the impression that it was the 
> Saxon-OracleXSL-Xalan-J axis that brought this about.
> 
> The political warning is that Microsoft as an axis of its own, has much 
> broader XSLT presence than the Java band, and a move that I'm guessing is 
> intended to make the Java implementations more attractive is *very* likely to 
> backfire as we all have to start dealing with transforms with embedded 
> VBScript.
> 
> At a stroke, the specification makes it more attrctive for Sun (just to pick 
> on someone other than Microsoft) to make its SVG slide toolkit only useful to 
> Java programmers.  As pure XSLT 1.0, it was useful to all.
> 
> This is a very bad thing.

  Agreed, just be prepared to receive tons of XSLT with C# embedded in it,
it's legal (just a specific language QName), an will be *very* tempting.
IMHO you can forget about any interoperability for dynamic styling on the
client side with XSLT.

  Yes this is sad, in perspective defining XPath to be a platform
independant, language independant, XML expression language was carrying
the hope of really breaking the interoperability problems and be able to
define styling and general purpose processing in an uniform way (at the
cost of the reimplementation of a new language). It can still be
used that way, but the XSL WG seems to have unfortunately dropped this
target.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@xxxxxxxxxx  | libxml Gnome XML toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

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