RE: [XPath 2.0] 3.5.2 General Comparisons

This problem does not only exist in backwards-compat mode but also when
you compare against untypedAtomic...

"If either atomic value has the dynamic type xdt:untypedAtomic, that
value is cast to a required type, which is determined as follows:

If the dynamic type of the other atomic value is a numeric type, the
required type is xs:double."

So I would like to extend this comment to cover the general comparison
in general...

Best regards
Michael


> -----Original Message-----
> From: public-qt-comments-request@w3.org [mailto:public-qt-comments-
> request@w3.org] On Behalf Of Michael Kay
> Sent: Friday, February 06, 2004 9:48 AM
> To: public-qt-comments@w3.org
> Subject: [XPath 2.0] 3.5.2 General Comparisons
> 
> 
> The current rules for backwards compatibility in general comparisons
> reads:
> 
> <old>
> If XPath 1.0 compatibility mode is true, and at least one of the
atomic
> values has a numeric type, then both atomic values are cast to to the
> type xs:double.
> </old>
> 
> [Note also the typo: "to to"]
> 
> This means that if both the values are xs:decimal values, they must
both
> be converted to xs:double values for comparison. This seems
> unreasonable, given that two xs:decimal values can be unequal when
> compared as decimals, but equal when converted to doubles.
> 
> Since it's entirely OK to compare two numeric values of different
atomic
> type, there doesn't seem to be a good reason for converting both
> operands to double, rather than only converting one; nor is there a
good
> reason for converting to xs:double if the value is already numeric. I
> suggest changing the rule to:
> 
> <new>
> If XPath 1.0 compatibility mode is true, and if one of the atomic
values
> has a numeric type and the other does not, then the value that is not
> numeric is cast to the type xs:double.
> </new>
> 
> Michael Kay

Received on Friday, 6 February 2004 15:29:38 UTC