higher-order-functions-059:

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 https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Mar/0065.html)

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.

higher-order-functions-060:

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.

higher-order-functions-061:

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.

higher-order-functions-65:

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.

Fixed as proposed in comment#1.

As regards test higher-order-functions-059, I have effectively reopened this as a spec issue in bug #28371.

The spec has now been changed so XPTY0004 is raised rather than XTTE0790 when the arguments to a function call have the wrong type.