This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The essence of K2-FilterExpr-8 is: (<?z?>, <?y?>)[self::processing-instruction(y)] treat as empty-sequence() The test only allows an XPDY0050 error. However since it can be statically determined that the query either raises an error or returns () it is safe to return () (or raise an XPST0005 error).
This line of reasoning is madness. It can be statically determined that the query raises an error, therefore it can be statically determined that it either raises an error or returns "A bunch of roses", therefore it is legitimate to return "A bunch of roses". I don't buy it.
To be a little more constructive: the only possible reason someone would use "treat as" is to say "if this is an T, carry on processing, otherwise raise an error". To implement this by assuming that the value is an T and not actually testing for the error condition is going directly against the user's intentions.
I will concede that () is not a desirable result, but am unconvinced that it is not a valid result. And indeed XQTS is intended to test for conformity, not reasonability. Whether or not this is allowed by the spec hinges on whether this is considered a cardinality constraint: XQuery 2.3.4: "There is an exception to this rule: If a processor evaluates an operand E (wholly or in part), then it is required to establish that the actual value of the operand E does not violate any constraints on its cardinality. For example, the expression $e eq 0 results in a type error if the value of $e contains two or more items. A processor is not allowed to decide, after evaluating the first item in the value of $e and finding it equal to zero, that the only possible outcomes are the value true or a type error caused by the cardinality violation. It must establish that the value of $e contains no more than one item." As I interpret this rewriting "treat as ()" as "()" is (barely) admissible since this does not require its argument to be evaluated. Under static typing any non-trivial expression that can only take the value () raises an XPST0005 error, so under static typing this error is certainly a reasonable (if not the only correct) result.
Ok, static typing is very... time consuming. Solved this the easy way; added a separate static typing query.