Subject: Re: [xsl] XSLT 1.1 comments From: Alexey Gokhberg <alexei@xxxxxxxxxx> Date: Tue, 13 Feb 2001 10:37:41 +0100 |
Hello > > 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, Alexey XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments, James Clark | Thread | Re: [xsl] XSLT 1.1 comments, James Clark |
Re: [xsl] XSLT 1.1 comments, Daniel Veillard | Date | RE: [xsl] XSLT 1.1 comments, Peter Flynn |
Month |