- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 30 Dec 2005 23:02:41 +0000
- To: www-xml-schema-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2625 Summary: Clause 3.3 of Derivation Valid (Restriction, Simple) unclear Product: XML Schema Version: 1.1 only Platform: PC OS/Version: Linux Status: NEW Keywords: unclassified Severity: normal Priority: P2 Component: Structures: XSD Part 1 AssignedTo: ht@w3.org ReportedBy: cmsmcq@w3.org QAContact: www-xml-schema-comments@w3.org The Schema Component Constraint: Derivation Valid (Restriction, Simple) in section 3.14.6 of Structures was modified in September to require among other things that 3.3 No member of {member type definitions} has the same {name} and {target namespace} as the containing Simple Type Definition itself. What is the meaning of "containing" in this rule? The term 'containing' is used in several ways in Structures. In the usual way, something can be contained in a set, or in a list. XML elements (and attributes, too) are contained by their parent elements. In more schema-specific usage, local components are said to be contained by the component to which they are local. Could "containing Simple Type Definition" mean the <simpleType> element which contains the declaration of another simple type? I can't see how: this is a constraint on components, not on XML. Could "containing Simple Type Definition" mean the simple type to which a particular other simple type is local? If so, what does the constraint mean or do? I do not understand what constraint this clause imposes. If we take 'containing Simple Type Definition' to mean the simple type definition being constrained, the one whose {member type definitions} is referred to (I see no parallels for this usage, but I am out of other candidate interpretations), then clause 3.3 seems to be trying to ensure that no union is a member of itself. But that is already accomplished in the status quo by clause 3.1, which requires that the members not be unions. (The WG has decided to eliminate that constraint, but the proposal to add 3.3 wasn't presented as a way of doing so.) Clause 3.3 also seems to apply only to named (i.e. top-level) types, and not to local types. In schemas derived from schema documents, I suppose it suffices to prevent cycles involving named types, because the XML syntax won't allow us to construct any other kind of membership cycles. But in born-binary schemas, we have no such guarantee. And this is a constraint on components, not on XML. I apologize for not having raised this question when we were considering the proposal to add this clause. But I think this clause urgently requires clarification.
Received on Friday, 30 December 2005 23:02:45 UTC