The argument against this is that a stylesheet user wants guarantees
that a script that they write will be usable on a variety of platforms
and under a variety of different XSL processors.  I think that at a
minimum, the processor must implement ECMAScript to be compliant.  I
have no problem if the vendor wants to extend that to include other
scripting languages.

Rob

>-----Original Message-----
>From:	Tony Stewart [SMTP:tony.stewart@xxxxxxxxxx]
>Sent:	Wednesday, March 04, 1998 10:50 AM
>To:	xsl-list@xxxxxxxxxxxxxxxx
>Subject:	RE: Style vs. transformation
>
>Sean McGrath wrote:
>
>"Is XSL inextricably linked to JavaScript as it scripting environment?
>If I implemented XSL with Python as its expression language would I be
>cast into utter darkness..."
>
>This is an issue we too care about (a lot). I'm hoping that the standard
>can be broadened (and made more generic and therefore more useful) by
>specifying a mechanism for shelling out to _any_ scripting language or
>available programming interface, not just JavaScript. I'll admit that if
>we must choose just one escape then JavaScript is a pretty good choice
>(perhaps the best), but it's not a panacea and there's no reason to
>handcuff ourselves to just one. Especially considering how quickly
>things change. Do we really want to rewrite the standard next year when
>something better than JavaScript comes along?
>
>Tony
>
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Tony Stewart
>RivCom
>"Publishing Structured Information"
>www.rivcom.com
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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