This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In his survey of the impact of precision decimal on XPath and XQuery (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2006May/0023.html) [member-only link], Don Chamberlin observes In 754r Section 5.10 we read "totalorder(-NaN, number) is true where -NaN represents a NaN with negative sign bit". (But there is no negative NaN value in XML Schema.) It would appear from this that IEEE 754R assigns distinct meaning, for ordering purposes, to the sign bit of NaN values. Our description of precisionDecimal requires the sign to be absent when the numericalValue is notANumber. Our float and double types have a NaN, but no negative NaN. If IEEE 754 does assign ordering or processing semantics to -NaN, it may perhaps be useful for XPath and the other QT specs if XSDL distinguishes NaN and -NaN. Should our description of NaN be modified to follow 754?
(In reply to comment #0) > In 754r Section 5.10 we read "totalorder(-NaN, number) is > true where -NaN represents a NaN with negative sign bit". > (But there is no negative NaN value in XML Schema.) > > It would appear from this that IEEE 754R assigns distinct meaning, > for ordering purposes, to the sign bit of NaN values. Our > description of precisionDecimal requires the sign to be absent > when the numericalValue is notANumber. Our float and double > types have a NaN, but no negative NaN. > > If IEEE 754 does assign ordering or processing semantics to > -NaN, it may perhaps be useful for XPath and the other QT > specs if XSDL distinguishes NaN and -NaN. It's true that 754R provides for this alternate total ordering (which differs from the usual not-quite-total ordering, also provided for). However, 754R in 7.12.1 prescribes that "quiet" NaNs are to be represented lexically as "nan" or some partially or entirely capitalized variant, and that "signaling" NaNs are to be similarly represented by "snan" or "nan". In either case, no sign is allowed. If we wish to cover the case of the sign bit of NaNs in out lexical representations, according to 8.2.1 we must in addition to "nan" (or the optional "snan") provide a bit patern that sets out all of the system-defined-meaning bits that can vary in the various NaNs. The WG considered and rejected long ago the option (IIRC, WRT float and double) of specifying such bit patterns. Need we reopen that question?
(In reply to comment #1) > allowed. If we wish to cover the case of the sign bit of NaNs in out lexical > representations, s/in out/in our/ Sorry. :-(
The editors discussed this on the editors' call this morning. Comment #1 may be in error in saying the lexical form '-NaN' is not allowed (section 5.12.1 appears to allow it, but explicitly says that it has no meaning). Section 6.3 says that IEEE 754R (draft 1.5.0, October 2007) does not interpret the sign bit of NaNs. The editors recommend to the WG that this issue be closed without change, as WORKSFORME.
At the telcon of 16 May 2008, the XML Schema WG adopted the proposal in comment #3 to close this issue as WORKSFORME.