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

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

--- Comment #19 from Jonathan Robie <jonathan.robie@gmail.com> ---
I just modified it as follows. I'm leaving this open until our next meeting.

Note:

Even though it cannot occur in an instance, xs:error is a valid type name in a
sequence type. Although the practical uses of xs:error as a sequence type are
limited, but they do exist. For instance, an error handling function that
always raises a dynamic error never returns a value, so xs:error is a good
choice for the return type of the function.

The semantics of xs:error are well-defined as a consequence of the fact that
xs:error is defined as a union type with no member types. For example:

    $x instance of xs:error always returns false, regardless of the value of
$x.

    $x cast as xs:error fails dynamically with error FORG0001, regardless of
the value of $x.

    $x cast as xs:error? raises a dynamic error FORG0001 if exists($x),
evaluates to the empty sequence if empty($x).

    xs:error($x) has the same semantics as $x cast as xs:error? (see the
previous bullet point)

    $x castable as xs:error evaluates to false, regardless of the value of $x.

    $x treat as xs:error raises a dynamic error [err:XPDY0050] if evaluated,
regardless of the value of $x. It never fails statically.

    let $x as xs:error := 1 return 2 raises a type error [err:XPTY0004], which
can be raised statically or dynamically, and need not be raised if the variable
$x is never evaluated by the query processor.

    declare function ns:f($arg as xs:error) {...}; is a valid function
declaration, but it always raises a type error [err:XPTY0004] if the function
is called.

All of the above examples assume that $x is actually evaluated. If the result
of the query does not depend on the value of $x. the rules specified in 2.3.4
Errors and Optimization permit an implementation to avoid evaluating $x and
thus to avoid raising an error.

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

Received on Thursday, 8 October 2015 21:21:08 UTC