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 28371 - [xslt30] XTTE0790 vs XPTY0004
Summary: [xslt30] XTTE0790 vs XPTY0004
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-30 08:15 UTC by Michael Kay
Modified: 2015-04-23 22:28 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2015-03-30 08:15:27 UTC
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.
Comment 1 Abel Braaksma 2015-04-17 14:23:15 UTC
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/ ;)
Comment 2 Michael Kay 2015-04-23 17:00:47 UTC
The proposal was accepted.
Comment 3 Michael Kay 2015-04-23 22:28:31 UTC
The change has been applied.