W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2007

[Bug 3239] Acyclicity of type derivation

From: <bugzilla@wiggum.w3.org>
Date: Thu, 27 Sep 2007 04:16:49 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Iaknx-00066D-DT@wiggum.w3.org>


cmsmcq@w3.org changed:

           What    |Removed                     |Added
                 CC|                            |cmsmcq@w3.org
           Keywords|                            |needsReview

------- Comment #1 from cmsmcq@w3.org  2007-09-27 04:16 -------
Thank you; good catch.  The text of 2.4.3 does indeed assume without
visible justification that the base type relation is acyclic.

The division of labor between the Datatypes spec and the Structures
spec has occasionally been the source of confusion and sometimes of
contention.  The base type relation is required to be acyclic by
clause 2 of the Schema Component Constraint: Simple Type Definition
Properties Correct, which appears in section 3.16.6 of Structures.  In
the current status-quo draft of Structures, it reads:

    2 All simple type definitions are, or are derived ultimately
      from, the ·simple ur-type definition· (so circular definitions
      are disallowed). That is, it is possible to reach a built-in
      primitive datatype or the ·simple ur-type definition· by
      following the {base type definition} zero or more times.

I believe (and here propose) (1) that the constraint quoted above
should appear in section 4.1.5 of Datatypes (and, more generally, the
contents of Datatypes 4.1.5 and those of Structures 3.16.6 should be
aligned), and (2) that section 2.4.3 Definition, Derivation,
Restriction, and Construction should be modified as follows.

a) After the definition of 'derived', insert the paragraph

    A datatype MUST NOT be derived from itself.  That is, the
    base type relation must be acyclic.

b) In the next paragraph, beginning "It is a consequence", change
"these definitions" to "the above" (or, alternatively, to "these
definitions and constraints").

c) (While we're mucking about with this part of the document) the
markup of the definition of 'derived' should itself be extended to
include the entire definition, instead of excluding the bulleted list
which provides the meat of the definition.

The resulting text of section 2.4.3 will read in part:

    [Definition:] Every datatype is associated with another datatype,
    its base type. Base types can be ·special·, ·primitive·, or

    [Definition:] A datatype T is immediately derived from another
    datatype X if and only if X is the ·base type· of T.

    More generally, [Definition:] A datatype R is derived from another
    datatype B if and only if one of the following is true:

      * B is the ·base type· of R.
      * There is some datatype X such that X is the ·base type· of R,
        and X is derived from B.

    A datatype MUST NOT be derived from itself.  That is, the
    base type relation must be acyclic.

    It is a consequence of the above that every datatype other than
    anySimpleType is derived from anySimpleType.

I'm setting the status of this to needsReview; it is only the change
to 2.4.3 that needs review, though.  The alignment of Datatypes 4.1
with Structures 3.16 will require a larger and more complicated
editorial proposal, which will also affect bug 3235 and bug 3954.
Received on Thursday, 27 September 2007 04:16:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:06 UTC