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 3239 - Acyclicity of type derivation
Summary: Acyclicity of type derivation
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P1 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: cluster: cycles
Keywords: decided, editorial
Depends on:
Blocks:
 
Reported: 2006-05-09 10:17 UTC by Michael Kay
Modified: 2009-02-13 00:02 UTC (History)
2 users (show)

See Also:


Attachments

Description Michael Kay 2006-05-09 10:17:57 UTC
QT approved comment:

In 2.6.3 there is an unstated assumption that the relation "B is the
base type of R" is acyclic.
Comment 1 C. M. Sperberg-McQueen 2007-09-27 04:16:48 UTC
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
    ·ordinary·.

    [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.
Comment 2 Dave Peterson 2007-09-28 15:55:48 UTC
the text of a, b, and c is approved by this date; the bug remains open until the remaining alignment text is approved; back to needsDrafting for the remaining text
Comment 3 C. M. Sperberg-McQueen 2008-05-31 02:52:35 UTC
Since the wording proposal in comment #1 actually suffices to address
the substantive issue raised, and the remaining work of checking the
alignment of Structures and Datatypes is (we believe) purely editorial,
I am marking this issue editorial.

Michael, as the originator of the issue and as our contact wtih the
QT working groups, would you please report on the substantive resolution to QT
and indicate by closing the issue that they are happy with the resolution
(well, satisfied if not happy), or by reopening it that they are not
satisfied?  If we don't hear from you within the next two weeks, we
expect to assume that silence implies consent.
Comment 4 Michael Kay 2008-05-31 07:50:23 UTC
>Michael, as the originator of the issue 

I'm happy to treat this as editorial, but that doesn't involve closing it...
Comment 5 Dave Peterson 2008-12-12 19:09:41 UTC
On 5 Dec 2008, the WG accepted a proposal, with some directed modifications that were not to be returened to the WG for further consideration; the result has been incorporated into the master datatypes.xml file, but a new SQ HTML version has not been generated.
Comment 6 Dave Peterson 2009-02-12 23:19:59 UTC
Pproposal approved as amended is now in the status quo and most recent LCWD.  Hereby marked FIXED.  Mike Kay, please mark it CLOSED unless you have a new objection.  (I assume you were OK with it when it was approved by the WG since you were present and didn't object.)  As usual, no action within two weeks will be assumed to mean concurrence.