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: 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

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.


 XSL-List info and archive:

Current Thread