This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Questions include: Is it defined on "value spaces", or "types"? In 4.2.1 of the datatype spec: "Every value space supports the notion of equality, ...". So it seems that "equal" is defined on "value spaces". Does this imply that two (unconnected) types (with the same value space) can have equal values? For example, hexBinary and base64Binary have the same value space ("the set of finite-length sequences of binary octets"). hexBinary value "00" and base64Binary value "AA==" both represent one byte of value "0". Then are the two values equal? But 3.11.1 of the Structures spec says "Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both". Here it seems to indicate something different. Is this a contradiction? Do the types have to be related by restriction or union? If type A restricts "integer" by setting "minInclusive=0", and B restricts "integer" by setting "maxInclusive=10". Now A and B are not related by restriction or union. But I still expect value "5" from both types (values spaces) to be equal. (If they have to be related by restriction or union, doesn't 3.11.1 of the structure spec need to be modified to be more strict, instead of simply saying "derived from"?) The commentator's views on these issues: "equal" should be defined on value spaces, because equal values are equal, no matter how they were lexically represented. Types used to generate equal (actual) values don't need to be related. As long as there exist a (primitive) value space to which both values belong, and the two values are equal in that value space, then they are equal. This means hexBinary and base64Binary can generate equal values, so can QName and NOTATION. Further on this, maybe the value space of "float" should (or already is) be a subset of that of "double", so that these types can generate equal values. See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0059.html
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002AprJun/0060.html Resolution: Discussed at the May 31 telecon. The WG divided the question into: R-151a: can types derived from the same primitive type, but not derived from each other, can have equal values? R-151b(i): should we make an explicit statement that the primitive value spaces are disjoint? R-151b(ii): should we add a note to the descriptions of base64Binary and hexBinary saying explicitly that their value spaces are disjoint? RESOLVED unanimously: to classify R-151a (on whether types derived from the same primitive type, but not derived from each other, can have equal values) as a clarification with erratum, and instruct the editors to draft an erratum saying yes they can. RESOLVED: to classify R-151b(i) as a clarification with erratum and instruct the editors to draft an erratum saying explicitly that the primitive value spaces are disjoint. On R-151b(ii) we considered a proposal to class it a clarification with erratum and to instruct the editors to draft an appropriate clarification. The proposal failed. Proposed text may be found at: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jun/0061.html Brief discussion of the text began at the June 20 telecon, but no detailed review of the text was done. Final revised text http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/0057.html approved at Sept. 13 concall. Erratum E2-46 added.