Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: Alexey Gokhberg <alexei@xxxxxxxxxx>
Date: Tue, 13 Feb 2001 10:37:41 +0100

> Alexey Gokhberg wrote:
> > For
> > vendors and users of non-Java XSLT processors XSLT 1.1 offers NOTHING in
> > addition to XSLT 1.0.

James Clark wrote:
> What about the ECMAScript binding?

ECMAScript binding does not offer much as well.

The main reason is that, by design, ECMAScript is not a "complete"
programming language. Instead, it just provides a convenient framework
for building various extensions (and ECMA-262 openly invites to build
such extensions).

In the real life, every ECMAScript vendor offers numerous language
extensions in his implementation. For example, Microsoft and Unicorn
both provide ECMAScript bindings for DOM, SAX2, XPath, XSLT, ActiveX,
etc. in their ECMAScript interpreters, but, not surprising, they do it
in a different way. Therefore, even if both vendors adhere to the
provisions of XSLT 1.1, the stylesheet, which is written for some
ECMAScript-enabled XSLT processor and which relies on any
vendor-specific ECMAScript extensions (say, XPath functions) could be
hardly portable to another XSLT processor - especially when <xsl:script>
is used. 

This makes the ECMAScript case very different from the Java (Python,
C++, etc.) case. When the developer needs a certain functionality in
Java (Python, C++, etc.), she usually implements this functionality as a
set of Java classes (or with the adequate means in another "complete"
programming language); potentially, this set of classes can be re-used
in all XSLT processors with the appropriate support of Java (or another
language). This is not possible in case of ECMAScript, since ECMAScript
additional functionality is usually implemented in some programming
language other than ECMAScript.

Another difficulty with ECMAScript is that the vendor of non-open-source
(non-GPL, non-NPL) XSLT processor, who wishes to implement ECMASAcript
binding for XSLT, will likely be forced to create his own implementation
of ECMAScript interpreter. I am not sure that there will be many vendors
willing to do so - many of them will probably prefer writing extensions
in their "native" programming language.

> The reason that only ECMAScript, Java and IDL have bindings in the spec
> is that they these are the only programming languages for which there
> are standard DOM bindings.  Our language binding is based on the DOM
> (I'm not a big DOM fan, but W3C standards have to work together and that
> makes DOM the only realistic choice) and the DOM only has standard
> bindings for ECMAScript, Java and IDL.

This demonstrates, how one wrong W3C decision can trigger a cascade of
other wrong decisions. First, languages other than Java and ECMAScript
were ignored in W3C DOM specification. Now this can be a good reason for
ignoring these languages in specifications which are using DOM.

Kind regards,


 XSL-List info and archive:

Current Thread