Subject: Re: [xsl] [exsl] EXSLT 1.0 - Common, Sets and Math From: Francis Norton <francis@xxxxxxxxxxx> Date: Tue, 06 Mar 2001 13:59:07 +0000 |
David Carlisle wrote: > > 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. > I wasn't objecting to the idea of putting the spec for it in a separate document - since Jeni has already done that in the draught to whose announcement Mike was replying - but his comment that ... >> it's probably an area >> where implementors will want to wait and see what the official >> standard comes up with. ... suggests that xslt functions should and will remain a vendor-scoped extension while xsl:script[@language="java" or @language="ecmascript] will be language-scoped. It is this combination that worries me. Also, the difficulties - as the thread has shown - appear to be eminently surmountable, and - to use Mike's term - vastly less "controversial" than xls:script itself. > 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. > This is a bit recursive isn't it? The exsl:function proposal is precisely to permit you to write functions in SXLT. The fact that you can't currently write functions in XSLT is the problem that we are trying to solve, not a reason for not solving it. The existence of exsl:function would make xsl:script mor tolerable to me whether or not is is part of xsl:script - it would be a potentially XSLT-portable alternative. And we are *not* in the current XSLT 1.0 situation. How about saxon:function? At the moment if I want to write a multi-document/key function I could do it in saxon in java, or in saxon in XSLT. Both portable to all current saxon users. Neither portable to non-saxon users. One legible to all XSLT users. So I would probably use saxon:function. Under XSLT 1.1 the java solution should become script-portable to all java XSLT engines, but the XSLT solution is stuck with being vendor-portable. So which should I use if I want my solution to be most portable? > > 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. > I think my illustration (above) of the difference between vendor-portability and script-portabality explains why I think this. It's like saying that building a new ring-road round London will speed traffic up because no-one will be tempted by it to make extra car journeys, and then being all astonished when the M25 turns into Europe's largest car park. > 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) > My question was, what is the reason that the *effects* of this feature - plus no exsl:function, please - don't matter. I honestly don't feel that this question has been answered. 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, Jeni Tennison | Thread | Re: [xsl] [exsl] EXSLT 1.0 - Common, David Carlisle |
Re: [xsl] Re: implements-prefix vs , David Carlisle | Date | [xsl] Re: implements-prefix vs impl, Dimitre Novatchev |
Month |