Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math

Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
From: David Carlisle <davidc@xxxxxxxxx>
Date: Mon, 5 Mar 2001 18:20:32 GMT

   Seriously, exsl:function is incredibly important for my motivation for
   investing time in xslt.

   What's the big "difficulty" with it? There's some end-game moves about
   exsl:return but the big questions seem to be about extending XPath or
   implementing com:eval, neither of which are requirements for

It seems to me that the current exslt draft mixes up two rather
different things, and separating them out might help.
One is a common namespace (or namespaces) for extension functions
and a suggested list of initial functions. This is largely non
controversial (I assume the existence of such a namespace isn't
controversial at all, one could argue a bit about the exact list of

Then there is a mechanism for defining functions with an XSLT-like
language. This is a lot harder to spec out (as the thread has shown)
and hiving that off to a separate document might help with getting a
common namespace agreed.

   If we ditch exsl:function and go ahead with XSLT 1.1 WD we end up with a
   situation where non-portable extension functions are more "portable" and
   more "standard" than extension functions written in XSLT. I know I've
   made this point before, but I haven't yet seen it addressed.

Ie we are in the current XSLT 1.0 situation. XSLT 1.0 allows extension
functions to be written in any language that allows one to write
functions, and which has a vendor supplied binding to XSLT. This doesn't
include XSLT as you can't write functions.

   OK, so I'll try to address it.

   [1] this situation won't matter because it's only temporary.

   Well, XSLT 2.0 Requirements are only in first WD, and have been up for
   less than a month. And support for implementing extension functions is
   only a "SHOULD". So if that nice useful xsl:script tool with the blade
   marked java and the spike marked ECMAScript succeeds in knocking a nice
   big hole below the waterline of the good ship "XSLT Portability", I
   don't see any sign of people standing by with a lifeboat ready to sprint
   out and bolt on an official xsl:function power-pump to bail it out and
   keep it afloat. My guess? "Well, it's sunk now, perhaps we can make it
   into this really cool submarine".

This seems to imply that xsl:script makes java or ecmascript written
extension functions more likely than is the case with XSLT 1.0.
I don't see how that would be the case. The main feature of xsl:script
is just that if you do have a java implementation you only need specify
the extension class once not separately for every processor.

   [2] it won't matter because XSLT is a leaf technology, not itself a
   building block for other XML technologies

   [3] it won't matter because xsl:script will make script extensions so
   much more attractive and portable that it will raise the overall level
   of portability and platform independence

Currently you can write extension functions in javascript for some
XSLT engines, and java for others. xsl:script won't change that, it will
give the possibility of specifying implementations in both languages
which might even help.

   But, given that most utility authors are unlikely to be equally skilled
   in java and ECMAscript (sure they both use curly brackets, but one's OO
   and strongly typed, and the other... well idiosyncratic might be the
   polite word) then anyone who needs to make functionality available in
   expressions will probably publish to the java user base or the
   ECMAScript user base. Except for some eccentrics who publish stuff for
   the rest. And the more successful the feature is, the deeper the cracks
   in the XSLT user base will grow.

That's the current XSLT 1.0 situation that xsl:script is trying to avoid.


    So what's the *real* reason that putting out
   xsl:script with with official java and ECMAScript bindings while pushing
   xslt extensions back to XSLT-2.0-with-luck doesn't matter?

I'm not on the WG so can't give the real reason, but it is at least
consistent with XSLT 1.1's stated aim of specifying features that are
_already implemented_ as extensions in more than one processor,
_all_ the java XSLT engines have java bindings, several XSLT engines have
javascript bindings. The 1.1 xsl:script proposal as far as i can see
adds essentially no functionality other than to normalise these existing 
binding mechanisms.  As far as I know no current system offers a
function in XSLT mechanism except saxon, and that's always seemed rather
more of an experimental feature not ready for being standardised.
(It could be standardised, but doing so seems to be out of scope for
1.1's stated aims)


This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit

 XSL-List info and archive:

Current Thread