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

Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math
From: Francis Norton <francis@xxxxxxxxxxx>
Date: Mon, 05 Mar 2001 17:42:38 +0000

Michael Kay wrote:
> Congratulations on pulling this together, sorry not to comment on earlier
> versions, the volume of mail has been impossible.
> I think it might be prudent to take <exsl:function> out of this, or at least
> park it in a separate section, on the grounds that specifying it is causing
> some difficulty, and it's probably an area where implementors will want to
> wait and see what the official standard comes up with.

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

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.

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".

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

Off the top of my head, it's used for Schematron, XSL FO, it's been
proposed for XML Query serialisation, it's being used in a project to
build an XML Schema engine, and it's going to get new projects built on
top of it with each month that goes by. Until and unless there's an
official general purpose XML transformation language, XSLT is what we

[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

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.

[4] it won't matter because portability and interoperability are no
longer core values of the XML project.

Ho ho, only joking... I trust...

I'm trying not to get too worked up about this. I know that you, Mike,
and James Clark and I'm sure the rest of the WG have an awesome
collective insight into the technical issues, and are surely plugged in
to the strategic loop. 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?


 XSL-List info and archive:

Current Thread