This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[This issue was originally raised by Stefan Wachter in November 2002. It was booked as Rec Comment R-181 and is now being transferred into Bugzilla.] When a list valued element or attribute is used as a key then the equality of the values is important. In the following example there are 3 lists with item types "Name", "double", "nameOrDouble": <simpleType name="l1"> <list itemType="Name"/> <simpleType> <simpleType name="l2"> <list itemType="double"/> <simpleType> <simpleType name="l3"> <list itemType="tns:nameOrDouble"/> <simpleType> <simpleType name="nameOrDouble"> <union memberTypes="Name double"/> <simpleType> Are these lists equal? 1. Items types of lists are different but item types of items are equal: <element xsi:type="l1">1.0 2.0<element> = <element xsi:type="l3">1.0 2.0<element> 2. Item types of lists are different but there are no items. <element xsi:type="l1"/> = <element xsi:type="l2"/> What are the exact rules for comparing lists? Originally raised in: http://lists.w3.org/Archives/Public/xmlschema-dev/2002Nov/0066.html Response from Henry Thompson on 18 November 2002, agreeing that the rules should be cleaned up. http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002OctDec/0051.html Proposal from Ashok Malhotra, 29 November 2003: http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2003Nov/0054.html Discussed at the 2004-02-12 telecon. Decided that we need new draft text based on current 2E. Discussed again at the May 2005 face to face meeting. Action NC2005-15: Datatype editors to resolve R-181 by defining identity and equality of lists in terms of pairwise member identity and equality, respectively. Note that we need both a 1.0 corrigendum and a wording proposal for 1.1. Because identity and equality are distinct relations in 1.1 but not in 1.0, the wording proposals will not necessarily be the same. This record is for the 1.1 version of this problem. See bug 2045 for the 1.0 corrigendum.
See bug 2047 for the corresponding change to Structures.
The Working Group discussed this issue in its face to face meeting of January 2006, and concluded that the clarification needed is editorial, not substantive. Accordingly, I'm marking this issue editorial, and hoping that the editors can revised the relevant parts of the specification before Datatypes leaves Last Call. For the record, the basic principles to be made clearer are (as suggested in the description): (1) empty list = empty list (2) the values of each primitive type are distinct from those of other primitive types, but ordinary types have value spaces which contain (some of) the same values as those of the primitives. So the answer to the original poster's questions are: if you mean 'l2' not 'l1', then yes the lists are identical, and yes, the two empty lists are identical.
Marked as RESOLVED/WONTFIX per the minutes http://www.w3.org/XML/Group/2006/01/xml-schema-ftf-minutes.html#Review_of_open_issues
bug reopened due to another comment from QT. is related to bug 2045 and bug 2047
At the ftf meetings of October 2007, the XML Schema WG discussed this issue together with the XML Query and XSL WGs (in the context of a discussion of bug 3243). QT vigorously argued that the direction outlined for this issue in the comments on bug 2045 and bug 2046 should be reversed and that XSDL should align with QT in treating the difference between atomic values and singleton lists containing those atomic values as a purely metaphysical distinction. After discussion, we agreed to instruct the editors to prepare wording proposals for Datatypes (bug 2046) and structures (bug 2047), in which it's made clear that for XSDL purposes singleton lists are not distinguished from the atomic values which are their list items. As far as we could tell, this would affect only identity constraints, since we couldn't think of any way to construct an enumeration or a fixed value constraint which would involve comparison of an atomic to a singleton list. (Further thought shows that a union of a pattern-restricted integer with a list of differently pattern-restricted integers would allow tests to be constructed.) These wording proposals will, we hope, be useful in achieving agreement on the correct technical direction. (That is, they are phase-1 proposals, not phase-2 proposals.) Before we make any final decisions, we should perform some due diligence to see if existing processors all do the same thing in these cases (and what that thing is) and whether existing schemas seem likely to be affected.
Some simple test cases have been constructed which illustrate the use of singleton lists and atomic values as key and keyref, and in enumerations; they are on the W3C server, with a test catalogue, in the directory http://www.w3.org/XML/Group/2007/12/a.vs.s/ (member-only link). These test cases may be useful in determining the behavior of current processors so as to point out things that need to change. (The WG's phase-1 decision on this issue was not conditional on the behavior of current processors, but it's nevertheless of interest. Preliminary tests suggest that some processors distinguish atomic values from singleton lists both in the key/keyref examples and in the enumeration examples; at least one processor distinguishes in the key/keyref case and not in the enumeration case.
Correction to comment #6: as comment #5 should have made clear to me, the WG has not reached a phase-1 agreement on this question; the drafting requested of the editors is intended to help lead to a discussion from which phase-1 substantive agreement can emerge. I'm removing the keyword 'editorial', which is no longer correct, and marking the issue both as 'needsDrafting' and as 'needsAgreement' to try to suggest the actual state of play.
A wording proposal is at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.b2046.html (member-only link)
The proposal mentioned in comment #8 was adopted by the WG at today's call. Email has been sent to Stefan Wachter reporting the resolution and asking for his feedback. http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008AprJun/0130.html The Working Group believes that the proposal adopted today resolves the issue, so I'm marking the issue accordingly.