[Bug 24048] [XT3TS] XTTE0780 or XTTE0790 errors usage for types conversion in higher ordered function test set

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24048

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 29 March 2015 12:58:23 UTC