13186 2011-07-09 17:23:24 +0000 editorial improvement: Constraints on XML Representations of Complex Type Definitions 2011-12-29 02:29:01 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 1.1 only All All RESOLVED FIXED resolved P2 major --- 1 gandhi.mukul David_E3 cmsmcq www-xml-schema-comments oldest_to_newest 50861 0 gandhi.mukul 2011-07-09 17:23:24 +0000 I'm reading the latest editor's draft of the XML Schema 1.1 Structures spec. In the section, 3.4.3 Constraints on XML Representations of Complex Type Definitions it's said: 2 If <restriction> is present under <simpleContent>, then the [children] of <restriction> must not include any two elements with the same expanded name in the Schema (xs) namespace, unless that expanded name is one of xs:enumeration, xs:pattern, or xs:assert. This seems to be missing the component xs:assertion in the list. Therefore this should be something like following, 2 If <restriction> is present under <simpleContent>, then the [children] of <restriction> must not include any two elements with the same expanded name in the Schema (xs) namespace, unless that expanded name is one of xs:enumeration, xs:pattern, xs:assertion or xs:assert. Thanks. 50890 1 gandhi.mukul 2011-07-11 03:44:29 +0000 I think the text I cited from spec should additionally include, xs:attribute and xs:attributeGroup as well. Therefore the XML representation of complexType as cited from the spec, may be modified to following, <proposed> 2 If <restriction> is present under <simpleContent>, then the [children] of <restriction> must not include any two elements with the same expanded name in the Schema (xs) namespace, unless that expanded name is one of xs:enumeration, xs:pattern, xs:assertion, xs:attribute, xs:attributeGroup or xs:assert. </proposed> Thanks. 51653 2 cmsmcq 2011-07-28 16:21:50 +0000 One problem with explicit lists of what can appear more than once is that they are so easy to get wrong (as this issue illustrates); another is that once the list is correct, the organizing principle may be unclear (which seems to me to be illustrated again here). So I propose a different change in wording to make the underlying principle clearer. How about 2 If <restriction> is present under <simpleContent>, then no facet-specifying element other than xs:pattern, xs:enumeration, or xs:assertion may appear more than once. This amounts to the same thing but is slightly clearer on what's going on, I hope. Also, we noticed in discussion that 3.16.3 needs to have references to xs:assert replaced with references to xs:assertion. 51654 3 David_E3 2011-07-28 16:23:12 +0000 Resolved: adopt the wording in comment #2. 51748 4 gandhi.mukul 2011-07-29 13:50:02 +0000 (In reply to comment #2) > One problem with explicit lists of what can appear more than once is that they > are so easy to get wrong (as this issue illustrates); another is that once the > list is correct, the organizing principle may be unclear (which seems to me to > be illustrated again here). So I propose a different change in wording to make > the underlying principle clearer. How about > > 2 If <restriction> is present under <simpleContent>, then no > facet-specifying element other than xs:pattern, xs:enumeration, > or xs:assertion may appear more than once. > > This amounts to the same thing but is slightly clearer on what's going on, I > hope. > > Also, we noticed in discussion that 3.16.3 needs to have references to > xs:assert replaced with references to xs:assertion. Thanks, Michael. The modified wordings proposed by you look nice to me as well. 62120 5 cmsmcq 2011-12-29 02:29:01 +0000 The change adopted in July has now been integrated into the status quo document at https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html#sec-src-ct (member-accessible link).