WG accepted this issue, Sandy Gao to produce

(Speaking for myself) I think the change is already mentioned.  The section on numeric types (I.2) mentions that float and double are now more closely aligned with IEEE mentions that NaN != NaN, and the section on "Other changes" (I.4) notes that enumerations, identity constraints (sic!), and value constraints all use equality not identity.  It seems to me that examples like the one shown in the description automatically follow from those facts.  

So my instinct is to close this issue with a disposition of WORKSFORME.  

If the idea is to add a sentence pointing out that in cases of enumerations including NaN and signed zero 1.1 and 1.0 processors may produce different results, I suppose it may be possible to find suitable wording (though I am skeptical).  But I think there is a limit to our ability to hold the reader's hand on matters like this.  It is not feasible to enumerate all the logical implications of our changes, and I do not think we should try.

(Also speaking for myself) I was not aware that this was mentioned implicitly, so it may be fair to reconsider our decision.

On the other hand, "compatibility" is vitally important to new versions of specifications. If data valid per the previous version becomes invalid per the new one, we need to make the users aware of that early.

This change around equality vs. identity for NaN is more worrisome than some of the other cases, because it may break existing completely meaningful usage of the spec. For other incompatible changes (for example, content model restriction, or fixed+prohibited attributes), we can argue that it's OK because that must not have been what the schema author intended. But NaN is different. It was sensible to define enumerations and fixed values with NaN, and it used to work.

So I do think we should try to list, explicitly, cases like this to educate the users (and ourselves) the consequences of changes we decided to make.

And if we reconsider this bug report, I would suggest that we go further than what was asked originally, and include "fixed value" and "identity constraints" as "no longer working as before" for NaN. Maybe by adding to I.4, "As a consequence ..."

Now I wish we had said "equal *or identical* to" for enumeration and fixed value. Maybe for identity constraints. This only affects NaN.

As a reference, the decision to use equality in these 3 cases was done in bug 3222, where part of the rationale for this change was to "reduce the impact of the incompatibilities".

On 27 August 2010 the WG discussed the proposal implicitly suggested in comment 3, of changing the rules for enumerations and value constraints to use identity OR equality of values.  The general sentiment of the group was to favor the change; some also favored using the same identity OR equality test for identity constraints.

We left the final decision for a meeting where more of the implementors were present.

<dezell> SG: two other things --
<dezell> ...: 1) two other places where we used to use equality, but meant identity, and now we say "equal" but the meaning of equal has changed.
<Sandy> 1.1 structure. 3.4.6.4 Content Type Restricts (Complex Content) "5.2.2 SVC.{variety}  = fixed and SVC.{value} is equal to GVC.{value}."
<Sandy> "4.2 Either G has no {value constraint}, or it is not fixed, or S has a fixed {value constraint} with an equal value."
* davep has quit IRC (Client exited)

On 28 January 2011 the WG considered the wording proposal at

    http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b9196.html
    http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b9196.html
    (member-only links)

and approved the proposals as submitted.

The change proposal mentioned in comment 6 has now been integrated into the status-quo documents; accordingly, I'm marking the issue resolved.  

Sandy, if as the originator you would close the issue?