This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following change is requested in F&O Section 17.1.1, "Casting from xs:string and xdt:untypedAtomic", Paragraph 6: Old text: "In casting to numerics, if the value is too large or too small to be accurately represented by the implementation, it is handled as an overflow or underflow as defined in Section 6.2, Operators on Numeric Values. Proposed new text: "In casting to xs:decimal, if the value cannot be accurately represented by the implementation, an error is raised [err:FOAR0002], In casting to numeric types other than xs:decimal, if the value is too large or too small to be accurately represented by the implementation, it is handled as an overflow or underflow as defined in Section 6.2, Operators on Numeric Values. Reason for change: These rules govern the interpretation of literals in queries. We believe that users have an expectation that decimal literals will be interpreted exactly and not rounded off. For example, if a user writes the decimal literal 1.00000...00001 which cannot be accurately represented by the implementation due to lack of precision, the implementation should alert the user by an error code rather than simply rounding the literal to 1.
A couple of comments: (a) casting from string to decimal should be consistent with schema validation. Casting shouldn't fail if validation succeeds. I believe that under these circumstances, validation does succeed. (b) I can certainly think of use cases where users would want the rounding behaviour rather than failure - not for literals, perhaps, but certainly for dynamically constructed strings. For example, if a decimal value is computed by an XQuery application running under one implementation, and is then serialized to an XML document which is transmitted over the network and read by an XQuery application running under a different implementation, and if the decimal value happens to be the result of dividing 1 by 7, then I think that the author of the application would not expect the receiving application to fail simply because the two XQuery implementations support differing decimal precision. They would expect to get whatever the lower-precision implementation supports. Michael Kay
Based on working group discussions, I submit the following revised proposal: In F&O Section 17.1.1 (Casting from xs:string and xs:untypedAtomic), add the following new paragraph following paragraph 6: In casting to xs:decimal or to a type derived from xs:decimal, if the value is not too large or too small but nevertheless cannot be represented accurately with the number of decimal digits available to the implementation, the implementation may round to the nearest representable value or may raise a dynamic error [err:FOCA0006]. The choice between rounding and error behavior is implementation-defined. In addition, add the following new error code to Appendix C: err:FOCA0006, String cast to decimal has too many digits of precision. In addition, add the following new item to the list of implementation-defined features in Appendix G: The result of casting a string to xs:decimal, when the resulting value is not too large or too small but nevertheless has too many decimal digits to be accurately represented, is implementation-defined. See Section 17.1.1.
At the joint Query/XSLT working group meeting on 21 March 2006, the proposal in Comment #2 was accepted by the working groups and will be implemented by the editors of the Functions and Operators specification. Therefore I am changing the status of this bug to Closed. --Don Chamberlin