27125 2014-10-22 14:11:51 +0000 [XSLT30] Rules of override-extension-functions and xsl:override 2014-10-24 14:05:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 113569 0 abel.braaksma 2014-10-22 14:11:51 +0000 This is a bug report that covers the unresolved part of https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0036.html and https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0039.html (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" override-extension-functions="no"> <!-- custom implementation, but if exsl:random-sequence (EXSLT.org) is supported, then processor should use internal version --> </xsl:function> Package B: <xsl:override> <xsl:function name="exsl:random-sequence" override-extension-functions="yes"> <!-- User wants to make use of the new fn:random-sequence of XP31 implementation using XPath 3.1 random sequence --> </xsl:function> </xsl:override> Result: [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": https://www.w3.org/XML/Group/qtspecs/specifications/xslt-30/html/Overview-diff.html#dt-compatible (member only), item 4 of the second bullet: <quote> 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). </quote> 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. 113699 1 mike 2014-10-24 14:01:17 +0000 The WG resolved to make the change. Note, for the record, that the justification for introducing this rule was in bug #22878.