Saxon

Thanks for reporting the issue you found. Yes this is a bug which is also reproducible on the Java platform.

Investigating it now.

Although the code to implement the xsl:function/@override-extension-functions attribute (or its previous name, @override) appears to be all in place, it looks to me as if it has been dormant and untested for some while.

I got this test case working after fixing three separate bugs:

(a) the compile-time function library used for binding simple static function calls in XSLT includes only one instance of StylesheetFunctionLibrary, containing the functions with override="yes", rather that (as intended) containing two instances, with different search precedence, one with override="yes" and one with override="no".

(b) the above error would be fatal were it not that the search for a function in the StylesheetFunctionLibrary ignores this property anyway.

(c) the overrideExtensionFunction property on a UserFunction object is set too late for it to affect forwards references from previous components in the stylesheet.

Bug fix committed and tested on the Java side (9.9 and trunk); fix needs confirming for .NET

Not fixed for 9.8

I confirm this has been fixed in Saxon 9.9 .NET.

The only change for the Call method in ExtensionFunctionCall is we return IXdmEnumerator.