[XPath] Operand conversion in arithmetic expressions

Prompted by a user, I have been re-reading the rules for converting the
operands of an arithmetic expression in section 3.4.

Rule 4 says:

4. If either operand is now of type xdt:untypedAtomic, it is cast to the
default type for the given operator. 

The effect of this rule is that in backwards compatibility mode, adding a
string "fred" to a number gives NaN, but adding an untypedAtomic value
"fred" to a number gives an error. This is clearly inconsistent, and it is
also incompatible with 1.0. The result should be NaN so that predicates like
//item[discount > price*0.25] continue to be error-free (an element with
discount="none" is not selected).


I think it would be useful to have two separate sets of rules, one for use
when compatibility mode is off and one for use when it is on. The rules with
compatibility mode on should read:

1. Atomization is applied to each operand.

2. If either operand is now an empty sequence, the result of the operation
is an empty sequence.

3. If either operand is now a sequence of length greater than one, any items
after the first are discarded.

4. If either operand is now of type xdt:untypedAtomic, it is converted to an
xs:double using the *number* function.

5. If the operand types are not valid for the given operator, then each
operand is converted to an xs:double using the *number* function. The
combination of atomic types that are accepted... [copy second sentence of
existing rule 5]

6. The operator is applied to the operands, resulting in an atomic value or
a dynamic error.

The rules when compatibility mode is off are unchanged. Rules 3a and 6,
which apply only to compatibility mode, disappear. Rule 7 might be better
moved to precede rule 5.

Michael Kay

Received on Thursday, 8 April 2004 09:56:10 UTC