W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2002

RE: xslt2 issues

From: Kay, Michael <Michael.Kay@softwareag.com>
Date: Fri, 4 Jan 2002 15:06:14 +0100
Message-ID: <DFF2AC9E3583D511A21F0008C7E6210622B8B6@softwareag.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>, xsl-editors@w3.org
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:17:52 UTC