This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13186 - editorial improvement: Constraints on XML Representations of Complex Type Definitions
Summary: editorial improvement: Constraints on XML Representations of Complex Type Def...
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2011-07-09 17:23 UTC by Mukul Gandhi
Modified: 2011-12-29 02:29 UTC (History)
1 user (show)

See Also:


Attachments

Description Mukul Gandhi 2011-07-09 17:23:24 UTC
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.
Comment 1 Mukul Gandhi 2011-07-11 03:44:29 UTC
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.
Comment 2 C. M. Sperberg-McQueen 2011-07-28 16:21:50 UTC
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.
Comment 3 David Ezell 2011-07-28 16:23:12 UTC
Resolved:  adopt the wording in comment #2.
Comment 4 Mukul Gandhi 2011-07-29 13:50:02 UTC
(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.
Comment 5 C. M. Sperberg-McQueen 2011-12-29 02:29:01 UTC
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).