This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XSLT 3.0 says (in 10.3.2, describing xsl:function/@param): The as attribute of the xsl:param element defines the required type of the parameter. The rules for converting the values of the actual arguments supplied in the function call to the types required by each xsl:param element are defined in [XPath 3.0]. The rules that apply are those for the case where XPath 1.0 compatibility mode is set to false. [ERR XTTE0790] If the value of an argument to a stylesheet function cannot be converted to the required type, a type error is signaled. Now, the second paragraph contradicts the first. If the rules for converting the values are those defined in XPath, then the error code is typically XPTY0004, except in some special cases where it might be FOTY0013 or XPTY0117 (or others?). The rule as written appears to apply both to static function calls and to dynamic function calls. It is problematic to apply XSLT-specific rules to a dynamic function call because there is no property of the function item that says "I am a stylesheet function"; in a dynamic call all functions are treated alike, regardless how they were implemented. Even for static function calls, it's not a good idea to have an XSLT-defined error code for a construct whose syntax and semantics are defined in XPath; for the implementor, this can only be achieved by modifying the behaviour of the XPath engine to conform to XSLT rules. I recommend that we delete this error code. The matter arises as a consequence of test suite bug #24048.
I would highly support this, because we run into the same issue, where targeting an inline XSLT function is treated the same way as a targeted inline XPath function and we simply don't have the means to distinguish between those case. So: s/XTTE0790/XPTY0004/ ;)
The proposal was accepted.
The change has been applied.