This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27125 - [XSLT30] Rules of override-extension-functions and xsl:override
Summary: [XSLT30] Rules of override-extension-functions and xsl:override
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2014-10-22 14:11 UTC by Abel Braaksma
Modified: 2014-10-24 14:05 UTC (History)
0 users

See Also:


Description Abel Braaksma 2014-10-22 14:11:51 UTC
This is a bug report that covers the unresolved part of and (member only) and related mail discussion.

Summary of that part:

The XSLT30 LCWD (Oct 2014) says that when you override an xsl:function and that function has override-extension-functions="no", then the overriding function must also specify override-extension-functions="no".

Use-case summary:

Package A:
<xsl:function name="exsl:random-sequence" 
       custom implementation, but if exsl:random-sequence (
       is supported, then processor should use internal version

Package B:
    <xsl:function name="exsl:random-sequence" 
          User wants to make use of the new fn:random-sequence of XP31
          implementation using XPath 3.1 random sequence

[ERR XTSE3070] It is a static error if the signature of an overriding component is not compatible with the signature of the component that it is overriding.

Relevant spec part:

Definition of "compability": (member only), item 4 of the second bullet:

If the overridden function specifies override-extension-functions="no" (or the equivalent using the deprecated override attribute) then the overriding function also specifies override-extension-functions="no" (or the equivalent).

Proposed solution:

Remove this rule (not the error), because it limits users choosing to switch to (new) internal XPath 3.1 or later, or XSLT 3.x or later functions as a preference over internal implementations and as such, limits extensibility and more importantly, inter-processor compatibility.
Comment 1 Michael Kay 2014-10-24 14:01:17 UTC
The WG resolved to make the change.

Note, for the record, that the justification for introducing this rule was in bug #22878.