This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XQTS contains two similar tests, K2-SeqExprCast-248 xs:integer(xs:float("INF")) which expects error FORG0001 (Invalid value for cast/constructor) and CastAs180 xs:float("INF") cast as xs:integer which expects error FOCA0002 (Invalid lexical value). Since construction and casting both normalize to the same form, these should surely expect the same error. Personally, I'd favour FORG0001. Relevant areas of the specification are: http://www.w3.org/TR/xquery-operators/#casting-to-numerics 17.1.3.3 Casting to xs:decimal 17.1.3.4 Casting to xs:integer "If SV is one of the special xs:float or xs:double values NaN, INF, or -INF, an error is raised [err:FOCA0002]." and http://www.w3.org/TR/xquery/#id-cast "If casting from the input type to the target type is supported but nevertheless it is not possible to cast the input value into the value space of the target type, a dynamic error is raised. [err:FORG0001] This includes the case when any facet of the target type is not satisfied. For example, the expression "2003-02-31" cast as xs:date would raise a dynamic error." Note that the latter does not even mention the possibility of FOCA0002.
The casting section of the XQuery book states "A summary of the rules are listed below the normative definition of these rules is given in [XQuery 1.0 and XPath 2.0 Functions and Operators]." So it's clear that the F+O definition is intended to take precedence. Whether we want to modify the text to align it at the level of defining error codes, I don't know.
I've changed our implementation to throw FOCA0002 in this case. The expected error is now correct in CVS, however our implementation disagress with the expected error code (FORG0001) for K2-SeqExprCast-254 to K2-SeqExprCast-331. These cases are of the form: some-type-derived-from-integer(xs:float("-INF")) where some-type-derived-from-integer includes xs:byte, xs:nonPositiveInteger, negativeInteger etc. I'll report these as errors against XQTS.
At the joint WG meeting on 2008-03-04, it was decided to change the language book to delete references to specific F&O error codes in the casting section, to remove conflicts and the potential for conflict. The language book already says that the F&O specification of casting is the normative one. I am changing the resolution to FIXED. Tim Mills, as the originator, if you agree with this resolution please change the status to CLOSED.
Thanks. Hopefully this can now be reflected in XQTS (Bug 5363).