Re: xslt2 issues

Hi Mike,

> I'm inclining to the view that the import precedence of a
> user-defined or vendor-defined extension function is established by
> vendor-defined mechanisms (e.g. by the import precedence of the
> <saxon:script> or <xalan:script> element that binds it), and that
> this in turn establishes whether it takes precedence over a
> stylesheet function created using <xsl:function>. We should have
> some rule that an external implementation of a function must only
> take precedence over an <xsl:function> if the user explicitly
> requests it by some such implementation-defined mechanism -
> otherwise the vendor would have carte blanche to make a call on a
> stylesheet function return anything.
>
> I think the mechanisms have to be vendor-defined, because a portable
> stylesheet actually needs to select different extension function
> implementations depending on the processor in use. They might want
> to write an <xsl:function name="exslt:random"> that's used in
> preference to Saxon's exslt:random, but not in preference to Xalan's
> exslt:random. This would mean that an explicit <xalan:script>
> element would be needed, even though the function is built-in, to
> raise its import precedence.

Gah, I hadn't been thinking about user-defined functions that are
defined with... what are they called now?... user-defined data
elements (which are actually defined by the vendor in this case).

So actually there are three types of function implementations that
might be available for a given function:

 A. a built-in implementation in the particular processor
 B. a user-defined function, implemented by the user in XSLT using
    xsl:function
 C. a user-defined function, implemented by the user in some other
    programming language using a 'user-defined data element'

[We need a way of distinguishing terminologically between A and C (and
B and C). You could view C as a 'vendor-defined function' since the
function definition is only available when using that particular
implementation. Or you could view C as a 'user-defined function' since
it's the author of the stylesheet, rather than the vendor, who's
written the implementation.]
    
I think that A should win over B and C in all cases.

Which should win between B and C is more difficult. Looking at the
EXSLT functions, there are some where the Javascript implementation is
way better than the XSLT implementation, and some where the opposite
is true. This can be because the other language is better at
expressing what needs to be done (e.g. regular expressions, dealing
with dates [I know these examples go away in XPath 2.0, but I'm sure
there will be more]) or it can be that some implementations are only
partial (for example, Javascript functions implemented with
msxsl:script cannot get information about the context node aside from
with an explicit argument).

In addition, there's the performance aspect - I imagine that in some
situations a Javascript (etc) function will work much better than an
XSLT function, and sometimes the opposite will be true.

I think that only vendors can decide how user(vendor)-defined data
elements actually work, so yes, the interaction between B and C has to
be up to the vendor.

But it does lead me to feel that there really needs to be a standard
xsl:script element (or similar) so that XSLT 2.0 can make clear
statements on the priority of user-defined functions written in
languages other than XSLT, rather than having to remember different
rules for different processors...

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 4 January 2002 10:09:15 UTC