[Bug 29119] [XP31] xs:error always raises a type error

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

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
> let $e as xs:error := xs:error()
> return 12

> which is XQuery, not XPath.

Indeed. Is the text from comment#0 agnostic? I.e. is it supposed to apply to
XSLT or other host languages as well that support typed variable bindings?

I believe I rose this bug report to signify that a binding (with or without a
type declaration) may exist, though evaluation will always throw an error. Of
course, early evaluation is allowed, but still, that shouldn't mean that
constructs like the one above fail, or this:

let $e as xs:error := xs:error('assertion failed')
return if(@assert) then 'success' else $e

I believe it should only fail when the if-statement is false, otherwise this
should not raise an error. Interestingly, currently this snippet won't compile
on Saxon (not even without the type specification), stating that a "Cast to
xs:error always fails" (9.6.0.5).

I don't think it should raise an error, and surely not statically. In fact, if
I replace the above xs:error with xs:int('assertion failed') it behaves as
expected (only raises if the if-statement fails).

Section 18.4 in FO31 seems to support this reading (in the Note), saying that
the error is dynamic:

    "Because xs:error has no member types, and therefore has an empty value 
    space, casting will always fail with a dynamic error except in the case 
    where the supplied argument is an empty sequence, in which case the 
    result is also an empty sequence."

This seems to make sense.

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

Received on Wednesday, 23 September 2015 04:27:48 UTC