W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2010

[Bug 9196] Enumeration and NaN

From: <bugzilla@jessica.w3.org>
Date: Wed, 18 Aug 2010 15:11:39 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1OlkIl-00014p-44@jessica.w3.org>

--- Comment #3 from Sandy Gao <sandygao@ca.ibm.com>  2010-08-18 15:11:38 ---
(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".

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 18 August 2010 15:11:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:10 UTC