This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 1917 - RQ-140: distinguish negative from positive zero in float and double (Requirement)
Summary: RQ-140: distinguish negative from positive zero in float and double (Require...
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Linux
: P2 critical
Target Milestone: ---
Assignee: XML Schema WG
QA Contact: XML Schema comments list
URL: http://www.w3.org/TR/xmlschema11-1/re...
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2005-08-30 18:22 UTC by C. M. Sperberg-McQueen
Modified: 2008-03-08 17:06 UTC (History)
0 users

See Also:


Attachments

Description C. M. Sperberg-McQueen 2005-08-30 18:22:22 UTC
The value space of float and double should be aligned with
IEEE and with the XML Query, XPath, and XSLT specifications
and should have two distinct signed zeroes.  

Historical background:  the first edition of XML Schema 1.0
had two distinct zeroes, but there was pushback over the
consequence that for purposes of checking minimum and
maximum values on bounded types +0 was greater than -0.
To respond to these concerns, the WG issued an erratum 
which made them a single value.  This in turn distressed some
observers who felt that alignment with IEEE and QT required
distinct signed zeroes.  Eventually, the WG concluded that the
correct approach is to have distinct values, but make 
bounds checking depend not solely on identity but instead
on numeric equality:  positive and negative zeroes are to
be distinct values which compare equal in bounds checking.
Since this is the behavior of conforming IEEE arithmetic
libraries, it should be unsurprising to most people, although
some observers have already deplored the distinction thus
made between identity and (numeric) equality.
Comment 1 C. M. Sperberg-McQueen 2005-09-07 22:19:21 UTC
A wording proposal for this issue is included in the omnibus package of
31 August 2005.

http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.omnibus.20050831.html
Comment 2 Henry S. Thompson 2005-10-28 11:05:30 UTC
New proposal sent to WG per decisions taken at telcon of 2005-10-21: 
http://www.w3.org/XML/Group/2004/06/xmlschema-
2/datatypes.b1917.20051028.html#float
Comment 3 C. M. Sperberg-McQueen 2005-12-09 04:00:10 UTC
I'm slighty uncertain of the current status of this item.
The wording included in the omnibus proposal of 31 August
was approved by the WG in Edinburgh, which would seem to have
closed the item.  I do not know why a revised proposal was
thought necessary (and wonder whether the proposal sent to the WG
in October was actually for a different issue related to
float and double).

In any case, the wording approved in Edinburgh was integrated
into the status quo document 8 Dec 2005.
Comment 4 Dave Peterson 2005-12-09 05:10:18 UTC
(In reply to comment #3)
>                            I do not know why a revised proposal was
> thought necessary (and wonder whether the proposal sent to the WG
> in October was actually for a different issue related to
> float and double).

Precisely; it was to close out the RQ-21 (lex reps and mappings, and
reformat to add a value space subsection) rewrite.

Which same was subsequently approved and is awaiting integration of
WG-directed amendments and then will be incorporated int SQ.
Comment 5 Dave Peterson 2008-03-05 16:06:11 UTC
(In reply to comment #4)
> (In reply to comment #3)
> >                            I do not know why a revised proposal was
> > thought necessary (and wonder whether the proposal sent to the WG
> > in October was actually for a different issue related to
> > float and double).
> 
> Precisely; it was to close out the RQ-21 (lex reps and mappings, and
> reformat to add a value space subsection) rewrite.
> 
> Which same was subsequently approved and is awaiting integration of
> WG-directed amendments and then will be incorporated int SQ.

No note indicating that the material described was in fact incorporated into the SQ document, but one editor (MSM) marked the material RESOLVED FIXED after that comment was posted, so I trust that they were so incorporated.  Michael, please check, and mark this bug CLOSED if they were in fact incorporated.
Comment 6 Dave Peterson 2008-03-08 17:06:00 UTC
(In reply to comment #5)

> No note indicating that the material described was in fact incorporated into
> the SQ document, but one editor (MSM) marked the material RESOLVED FIXED after
> that comment was posted, so I trust that they were so incorporated.  Michael,
> please check, and mark this bug CLOSED if they were in fact incorporated.

Oops. ' Twas not this bug that was referred to as needing a rewrite, it was "the
RQ-21 rewrite" (which happens to be bug 1907), which has been put in the SQ
document and CLOSED.  Accordingly, I retract the request for checking, and am
herewith marking this bug CLOSED.  Mea culpa.