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 24048 - [XT3TS] XTTE0780 or XTTE0790 errors usage for types conversion in higher ordered function test set
Summary: [XT3TS] XTTE0780 or XTTE0790 errors usage for types conversion in higher orde...
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 Test Suite (show other bugs)
Version: Working drafts
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Abel Braaksma
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2013-12-10 13:41 UTC by Vitaliy
Modified: 2015-04-23 22:29 UTC (History)
2 users (show)

See Also:


Description Vitaliy 2013-12-10 13:41:13 UTC
There are a couple of test cases which expects XPTY0004: 
- higher-order-functions-059
- higher-order-functions-060
- higher-order-functions-061
- higher-order-functions-065

But at the same time specification contains more specific error codes for this tests:
1) In the case of stylesheet function result type - [ERR XTTE0780] If the as attribute is specified, then the result evaluated by the sequence constructor is converted to the required type, using the function conversion rules. It is a type error if this conversion fails. 
2) In the case of stylesheet function parameters - [ERR XTTE0790] If the value of a parameter to a stylesheet function cannot be converted to the required type, a type error is signaled.
Comment 1 Abel Braaksma 2015-03-29 12:58:21 UTC

After giving this considerable thought, I came to the conclusion that this test  should not raise XPTY0004. Reasoning:

* Function arguments follow the function conversion rules
* Function items must be coerced into a wrapper function of target signature
* Only if arity is unequal, XPTY0004 is raised (acc. to XPath30)
* Arity is unequal for substring-before(?, ' ', ?) which has two arguments
* The function call will not proceed because this error must be raised during coercion (but see

Since this means that the argument of the function-call is of the wrong type, the expected outcome should be XTTE0790 (and not XPTY0004).

Because early evaluation of the function body (which returns the empty seq.) could result in a static type error (resulting in XTTE0780, as Vitaliy mentions), I propose to change the body of the function to actually do something and return a string.


Following the coercion rules and wrapping the function items into a new function of type function(xs:string) as xs:string*, take the fourth in $ops (string-length#1) and call if $F:

function($x as xs:string) as xs:string* {$F($x)}

In this case, Vitaliy's assessment is wrong. The coercion succeeds, but the actual call to the coerced function never takes place. However, because $F($x) returns an integer and is not convertible to xs:string, this MAY raise a static XPTY0004, but because that would be raised in the coercion phase, it should then be XTTE0790.

I propose to fix the test to actually call the function items inside the local:apply body, which forces the XPTY0004 (and not XTTE0780/0790) to be raised. However, XPath still allows the error to be raised during coercion, meaning XTTE0790 is also allowed.


Similar to the previous function coercion. Here the third item in the $ops sequence is function($x as xs:double){string($x)}), call it $F, coercion creates:

function($x as xs:string) as xs:string* {$F($x)}

The coercion succeeds, but MAY raise a static XPTY0004, but for the rest, the same arguments apply as with the previous test. That means that XTTE0790 is also allowed if the error is reported during coercion and not on the call.

I propose to fix this the same way as the previous.


Again, same as previous, even though it is more indirect. Function item upper-case#1 as $F is wrapped in:

function($x as xs:double) as xs:double { $F(#x) }

Which means that coercion succeeds, thought the obvious type error may be raised as during the coercion phase, leading to XTTE0790, or later when the function call is made inside local:round, leading to XPTY0004.

I propose to fix this by allowing XTTE0790 as an alternative error.
Comment 2 Abel Braaksma 2015-03-29 15:49:13 UTC
Fixed as proposed in comment#1.
Comment 3 Michael Kay 2015-03-30 08:17:19 UTC
As regards test higher-order-functions-059, I have effectively reopened this as a spec issue in bug #28371.
Comment 4 Michael Kay 2015-04-23 22:29:56 UTC
The spec has now been changed so XPTY0004 is raised rather than XTTE0790 when the arguments to a function call have the wrong type.