Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

[Robin Berjon <robin@knowscape.com>]

At 02:42 02/03/2001 -0500, Charles Reitzel wrote:
>Well, Javascript works pretty well on millions and millions of browsers.
>Runs on a most web servers, too.  Folks have been integrating it into Apache
>SOAP with some success.  Probably not a screamer, performance-wise.  But
>probably not the bottleneck, either.  Your mileage may vary.  If you don't
>like it, don't use it.  It is optional, after all.  

I'm not complaining about Ecmascript/Javascript. It's a poor excuse for a
language but this wouldn't be the appropriate forum to discuss this. I'm
not complaining about the idea of making XSLT extensible through language
bindings either, that's imho a good thing.

We're currently working a lot on SVG here, and most of what we've been
doing has been to create extension elements to SVG using Ecmascript.
Someone wanting to use extended functionality would simply link in the
appropriate ecmascript library, declare the ksvg namespace, and start
including our extension elements. You simply throw in a <k:foo/> element in
your group and it gets the foo functionality.

That works well. My only grievance (apart from the fact that ecmascript is
a real pain to use) is that these extensions are wired directly to
ecmascript, and that's a pity. It works ok for SVG because all one does is
manipulate a DOM, and that's somethings ecmascript isn't too bad at. People
won't use ecmascript in XSLT if they want say powerful formatting
functions. They'll use something less portable and less simplistic (eg
Java). I think there's a strong case for making the implementation of the
extension separate from the stylesheet, as described in Clark's xbind example.

I don't think the argument "it works for HTML/SVG/whatever" holds for XSLT.
It's a totally different kind of markup language, and throwing script into
it simply because it works elsewhere might not be so wise.

-- robin b.
There's too much blood in my caffeine system.