[XPath] Converting to a number in backwards compatibility mode

This comment was originally raised on an internal list just before the Last
Call drafts went out. I am re-raising it here so it can be managed as a
last-call comment.

 

Previously:
http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Nov/0010.html

 

In the function calling rules, when we need to convert a string to a number
under the backwards compatibility rules, we use the number() function.
 
In arithmetic expressions, we also use the number() function (the rules are
defined by reference to the function calling rules).
 
In a general comparison, when we need to do such a conversion, we currently
use the casting rules.
 
The difference is that if the value being converted is say "fred", or "",
the number() function will convert it to NaN, while casting will throw an
error.
 
With XPath 1.0, the comparison ["fred"=3] returned false, because 3 was
converted to a string and compared not-equal to the string "fred". The
comparison ["fred">3] also returned false, because the string "fred" was
converted to the number NaN, and NaN>3 is false. Under the current XPath 2.0
rules, both these comparisons will cause an error.
 
Since this rule is only there for backwards compatibility, we seem to have
got it wrong. I think that for general comparisons, as with the other two
cases, the backwards compatibility behavior should use the number() function
rather than the casting rules.
 
Michael Kay