- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 05 Oct 2004 13:33:21 +0100
- To: Ashok Malhotra <ashok.malhotra@oracle.com>
- Cc: w3c-xml-query-wg@w3.org, w3c-xsl-wg@w3.org, SWBPD list <public-swbp-wg@w3.org>
Ashok Malhotra wrote: > "3.2"^^xsd:float and "3.2"^^xsd:decimal will compare equal. > Decimal gets promoted to float. so eq is non-transitive? ... e.g. "3.2000000000000000000000000000000000000000000000001"^^xsd:decimal is eq to the float, but not eq to "3.2"^^xsd:decimal. Oh yes, XPath2 says http://www.w3.org/TR/2004/WD-xpath20-20040723/#id-value-comparisons [[ It is also recognized that transitivity of value comparisons may be compromised by loss of precision during type conversion (for example, two int values that differ slightly may both be considered equal to the same float value because float has less precision than int). ]] This makes it harder to see how to induce a denotational semantics for XML Schema datatypes from the Xpath work, other than the straight forward, but non-intuitive "all primitive datatypes are different" one. Maybe it's mainly type promotion that is the concern: http://www.w3.org/TR/xpath20/#promotion which only impacts decimal to float/double conversions. I've still to read the XQuery formal semantics doc, am I likely to find anything related to this problem there? Another one of the surprises for me was that hexEncodedBinary and base64EncodedBinary always compare not equal, even if the binary that has been encoded is the same. Is this still being worked on? Or has there been a WG decision on that? Jeremy
Received on Tuesday, 5 October 2004 12:33:35 UTC