This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It is unclear whether () op Arg should always return () regardless of whether the operator is defined for the type of Arg. For an example, see XQTS test K-NumericAdd-38: empty((1, 2) + ()) The expected result is the empty sequence. From XQuery section 3.4: "Each operand is evaluated by applying the following steps, in order: 1. Atomization is applied to the operand. The result of this operation is called the atomized operand. 2. If the atomized operand is an empty sequence, the result of the arithmetic expression is an empty sequence, and the implementation need not evaluate the other operand or apply the operator. However, an implementation may choose to evaluate the other operand in order to determine whether it raises an error. 3 ... This implies that, by step 2, we can determine that the result of the expression is the empty sequence. We could therefore have written an expression such as: () + "a string" and determined that the result is the empty sequence, even though fs:plus is not defined on string arguments. If this is the correct interpretation, then the typing rules in "C.2 Mapping of Overloaded Internal Functions" should be extended to cover this case. Specifically, they do not cover the case of binary operators when one of the arguments is the empty sequence and the other has a type not ordinarily supported by that operator.
Tim, This is a personal answer to this. Even though () + "a string" could be returning () in some implementations. I would think it makes sense to return a static type error for such cases. One reason is that it seems natural to me for a statically-typed implementation to warn the user about it. A stronger technical reason is that some implementation may indeed return a type error and that you want the static type system to prevent that at compile time. - Jerome
Thanks. That seems reasonable, although it will require a few changes in XQTS. Could this behaviour be made clear in the specifications, and specifically whether this behaviour is dependent on the static typing feature being implemented?
Here's my take on this. For the expression: empty((1, 2) + ()) Two possible outcomes are conformant behavior: * That it evaluates to the boolean value true. This is by that the right operand is evaluated first(and it only). The cardinality error in the left operand is not discovered and the arithmetic expression evaluates to the empty sequence. * The left operand is evaluated first and a type error, XPTY0004, is raised. This is governed by 3.4 which states how each operand is treated, but also that "The order in which the operands are evaluated is implementation-dependent." If I'm not mistaken, K-NumericAdd-38 has the text baseline "true" and the error baseline XPTY0004 to accommodate this. So I don't see that the specs needs to be changed for this, it's sufficiently covered. But unfortunately, error reporting continues to be a tricky and blurry area, and I doubt editorial touches would help.
"The order in which the operands are evaluated is implementation-dependent." Of roucse, during static type checking nothing has actually been evaluated.
(In reply to comment #0) > ... the typing rules in "C.2 Mapping of > Overloaded Internal Functions" should be extended to cover this case. > Specifically, they do not cover the case of binary operators when one of the > arguments is the empty sequence and the other has a type not ordinarily > supported by that operator. It seems to me that they *do* cover this case. Specifically, in C.2 / STA, the 2nd and 3rd rules allow you to conclude that the expression's type is empty if either operand's type is empty, regardless of the other operand's type.
So they do. That clears that one up then - thanks.