W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2005

[Bug 2625] Clause 3.3 of Derivation Valid (Restriction, Simple) unclear

From: <bugzilla@wiggum.w3.org>
Date: Fri, 30 Dec 2005 23:02:41 +0000
To: www-xml-schema-comments@w3.org
Cc:
Message-Id: <E1EsTGj-0000F7-KM@wiggum.w3.org>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:10 GMT