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. > What?! 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. 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 use. [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? Francis. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] [exsl] EXSLT 1.0 - Common, Michael Kay | Thread | Re: [xsl] [exsl] EXSLT 1.0 - Common, David Carlisle |
RE: [xsl] Cache problem, Adam Van Den Hoven | Date | Re: [xsl] XSL,Javascript, NS 4.x, Robert Koberg |
Month |