This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] EXSLT 1.0 - Common, Sets and Math
Francis:
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
exsl:function.
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
functions)
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)
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.star.net.uk/stats.asp
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list