This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT-approved comment. Having introduced the notion of equality of values (as distinct from identity) it is surprising that it is not used more widely, for example in applying enumeration facets, fixed values, or referential integrity constraints (the term "identity constraints" is a little unfortunate). Generally, the closer we can align the XML Schema comparison semantics with the XPath comparison semantics, the fewer surprises there will be for users. Furthermore, the distinction is not always carried through. For example, I would have expected section 2.6.1.2 to say how the notions of identity, equality, and ordering apply to the values of a list type. Is this somewhere else, and if so, should there be a cross-reference? I would also expect a more formal statement that the value space of a list type is the set of sequences of values of the item type, minus any values of the item type all of whose lexical representations contain whitespace. As with lists, one would expect section 2.6.1.3 to contain a discussion of the identity, equality, and ordering relations applicable to union types.
The WG discussed this issue at the ftf meetings of October 2007, first as a digression from bug 3245 and then in its own right. The primary arguments voiced against making changes here were (1) that since we worked hard to introduce the distinction between identity and equality in 1.1, it would feel dumb to eliminate it in effect by making nothing particular depend on identity and (2) that it would feel dumb to use anything other than identity for what we call *identity* constraints. Over the course of the discussion, the WG came to believe that these both amount merely to a fear of losing face, and that they have no technical force. It was proposed that we could still usefully distinguish identity from equality, for purposes of clarity (and as a touchstone for operations intended to be identity-preserving, such as storage and retrieval), and that we can have a note saying simply that the term "identity constraint" is a misnomer preserved for historical reasons. (After the fact, some WG members also pointed out that what identity constraints are concerned with is the identity of the element carrying the key, not the identity of the field values themselves. So it's misguided to think there is any real contradiction in using equality for identity constraints.) It was also pointed out that using equality rather than identity would reduce the impact of the incompatibilities incurred by our change from 1.0 to 1.1. This proved persuasive. In the end, we agreed to instruct the editors to prepare draft wording to make all tests use equality and to tell a rational story about identity. Rationale: soften the compatibility issues involved in our changes since 1.0. None were opposed, but we noted that a change to equality or identity of strings might undercut our consensus on this.
A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b3222.html (memnber-only link).
The wording proposal mentioned in comment #2 was adopted by the WG at today's call; with that, I am marking the issue resolved. Michael, as the originator of the issue and as our contact wtih the QT working groups, would you please report on the resolution to QT and indicate by closing the issue that they are happy with the resolution (well, satisfied if not happy), or by reopening it that they are not satisfied? If we don't hear from you within the next two weeks, we expect to assume that silence implies consent.