- From: Michael Kay <mhk@mhk.me.uk>
- Date: Mon, 16 Feb 2004 16:47:32 -0000
- To: "'Xan Gregg'" <xan.gregg@jmp.com>, <public-qt-comments@w3.org>
>XSCH-FO-005 Casting xs:double and xs:float to xs:string (17.7) >We note that F&O does not use the XML Schema canonical representations of xs:decimal, >xs:float, and xs:double. We know that XML Schema is under-specified in this area, and we >are working to improve our specification in either errata fixes or a future version (see our >RQ-1, http://www.w3.org/XML/Group/2002/07/xmlschema-1.1-current-reqs-list.html #canonical-float). >We suggest that we coordinate efforts to find a mutually satisfactory resolution. Note that casting numbers to strings is used in two different circumstances, and the rules are designed to achieve a balanced compromise between two different requirements. These casts are used both when writing a value to an XML document to be serialized, and also when displaying a value to a human user. There is also a requirement for a reasonable level of backwards compatibility with XPath 1.0. If we used the Schema canonical representations unchanged, then many existing stylesheets would start outputting "Chapter 1.0e0". >That aside, we suspect the written descriptions do not have their intended effect. If SV has an absolute value that is greater than or equal to 0.000001 (one millionth) and less than 1000000 (one million), then the value is converted to an xs:decimal and the resulting xs:decimal is converted to an xs:string using the rules above. >The casting to decimal rules imply that casting xs:float("1.1") to xs:decimal yields 1.10000002384185791015625 which is the exact value of the float that represents "1.1" (and therefore it is the "numerically closest" value). Does this mean casting xs:float("1.1") to string yields "1.10000002384185791015625"? We are planning to reintroduce the XPath 1.0 rule that specifies that the output should contain as many digits, and only as many, as are needed to distinguish the value from adjacent values. Michael Kay (personal response)
Received on Monday, 16 February 2004 11:46:56 UTC