RE: EcmaScript, gone?

While I don't wish to exclude other languages, I think it's important for
cross-platform compatibility that the standard require that a certain
language *always* be present.

This is analogous to the way XML handles character sets.  The XML spec
allows you to encode your XML in whatever character set you like, but it
mandates that all XML processors must be able to handle UTF-8 and UTF-16.
You can use whatever character set you like, but you can be assured that at
the least, UTF-8 and UTF-16 will always be available.

IMO, This is an excellent approach.  It allows flexibility for those that
are willing to live outside the "lowest common denominator", yet creates a
powerful enough LCD that most people don't need to step outside the spec.

I would apply this same approach to scripting.  I would allow any language
choice to be used, but mandate that in order to be compliant with the spec,
an XSL processor must implement ECMAScript at a minimum.  Additional
languages would be optional.  To not do so would throw us back into the dark
ages of the browser wars.

Rob


-----Original Message-----
From: James Clark [mailto:jjc@xxxxxxxxxx]
Sent: Thursday, September 03, 1998 12:02 AM
To: xsl-list@xxxxxxxxxxxxxxxx
Subject: Re: EcmaScript, gone?


- The extension mechanism is independent of any single
programming/scripting language.

- An XSL implementation is free to choose which if any languages
they support this standard mechanism for. It may allow extensions to
be implemented using a non-standard mechanism instead.  For example, a
WYSIWYG editor has stringent implementation constraints which may make
it impractical for such editors to support the standard mechanism.
Such an implementation might choose to support an extensibility
mechanism tailored to its implementation needs.


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