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 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] EXSLT 1.0 - Common, Francis Norton | Thread | Re: [xsl] [exsl] EXSLT 1.0 - Common, Jeni Tennison |
Re: [xsl] translate (string, '', Jeni Tennison | Date | RE: [xsl] substrings with entities , Adam Van Den Hoven |
Month |