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 6204 - anyType/ur-Type: inconsistent whether it has a base-type
Summary: anyType/ur-Type: inconsistent whether it has a base-type
Status: RESOLVED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: unspecified
Hardware: Other Linux
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: editorial, resolved
Depends on:
Blocks:
 
Reported: 2008-11-03 15:14 UTC by Frans Englich
Modified: 2009-03-16 13:35 UTC (History)
1 user (show)

See Also:


Attachments

Description Frans Englich 2008-11-03 15:14:47 UTC
Section 2.2.1.1 Type Definition Hierarchy reads:

"[Definition:]  Except for ·xs:anyType·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy."

which implies that xs:anyType doesn't have a base type, since it makes xs:anyType a exception, and states that the type graph is a tree, and as far as I know circular trees does not exist(at least no one grows over here in Scandinavia).

However, section 3.4.7 Built-in Complex Type Definition specifies the {base type definition} for xs:anyType to be "itself", which implies circularity.

To me it seems that section 3.4.7 is wrong and its {base type definition} should be "none".
Comment 1 David Ezell 2008-11-21 17:23:31 UTC
On the telcon, the WG decided to change prose in and around the definition from 2.2.1.1, but to decline to make any deeper change.
Comment 2 David Ezell 2008-11-24 15:20:34 UTC
Telcon 2008-11-21
Not really a bug, just a subtlety of the wording.  While we can no
longer recall the reason for making anyType have itself as its own base,
now is not a good time to be changing it.

RESOLVED: Classify 6204 as Editorial, to clarify the prose in the
definition of the type definition hierarchy in 2.2.1.1.
Comment 3 Sandy Gao 2009-03-16 13:35:26 UTC
During its 2009-03-13 telecon, the schema WG adopted a proposal to address this issue.

The change is to replace the "Type Definition Hierarchy" definition:

"[Definition:]  Except for ·xs:anyType·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The graph of these relationships forms a tree known as the Type Definition Hierarchy."

with the following:

"[Definition:]  Except for ·xs:anyType·, every ·type definition· is, by construction, either a ·restriction· or an ·extension· of some other type definition. The exception ·xs:anyType· is a ·restriction· of itself. With the exception of the loop on ·xs:anyType·, the graph of these relationships forms a tree known as the Type Definition Hierarchy with ·xs:anyType· as its root."

With this change, the WG believes that the issue raised in this bug report is fully addressed. I'm marking this RESOLVED accordingly.

Frans, as the persons who opened and reopened this issue, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.