Re: XSLT 1.1 comments

Alexey Gokhberg wrote:
 
> 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.

So does every C and C++ vendor.

> 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)

The C and C++ standards make no attempt to be complete in this sense.
Even something as simple as retrieving a URL requires use of operating
system dependent features. Java does go along way to this kind of
completeness.  If only it were a real standard! I don't know of any
programming language which

(a) has a real standard (ISO, ECMA, ANSI or something similar), and
(b) doesn't need extension beyond the standard to perform many
real-world tasks

> 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.

You can use the NPL-licensed ECMAScript implementations in
non-open-source products.

Also on Windows, you can use the Microsoft implementation.

James


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