RE: xslt2 issues

> On the other hand, since reasonable people can obviously differ so
> markedly in their expectations over which should win, a switch sounds
> like a good idea (though I'd prefer that it was defined within XSLT,
> perhaps allowed on a function-by-function basis through an attribute
> on xsl:function, rather than left up to vendors).

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.

Mike Kay

Received on Friday, 4 January 2002 09:06:20 UTC