Re: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file)

[Ray Cromwell <ray@xxxxxxxxxxxxxxx>]

For client side scripting on the browser, I think that not choosing
a standard scripting language is a mistake. Sure, it's all well and
nice that you can plug in whatever scripting language you want.
But let's face facts -- web developers will use the language
that has the greatest reach. If I am forced to download and
install another plugin/COM object (and how do I do this crossplatform?),
I will not visit that web page.

For server side, it doesn't matter, but for anything on the client,
I'd argue for making JavaScript and Java the defacto standards.
Specifically, JavaScript.


Sure, I love my perl, but I'd forgo the use of all my languages if
I can depend on the end user being able to view my CSS/XSL/DHTML/JavaScript
page on multiple platforms and browsers without regard to their local
configuration.

If instead, I tried to use client-side PerlScript in IE4/5, who could
actually display my page? And what would be the advantage anyway?


Isn't there an adage "things left unspecified have a way of specifying
themselves?"  Why not spec ECMAScript as *required* for a conforming
parser? There are even free implementations of ECMAScript in Java
and C.

My sincere wish is that 3 years from now, I can depend on DOM
being the universal interface to HTML/XML, and every browser/OS
has built in 100% compliant CSS/XSL/DOM/EcmaScript support.









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