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 3241 - Type hierarchy
Summary: Type hierarchy
Status: RESOLVED LATER
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: important, work
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-09 10:36 UTC by Michael Kay
Modified: 2007-08-24 21:01 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2006-05-09 10:36:47 UTC
QT approved comment:

Type hierarchy:

At the same time as introducing anyAtomicType, might not there be some sense in introducing anyListType and anyUnionType, and perhaps even anyComplexType?

[For example, I think it would be useful on occasions in XSLT/XQuery to determine whether the type of an attribute is list-valued, and this could be done as "@a instance of attribute(*, xs:anyListType)". There are other solutions, such as introducing metadata interrogatives.]
Comment 1 David Ezell 2007-04-20 15:19:15 UTC
On 2007-04-20 the editors discussed this issue.  They respectfully suggest that this issue is likely to have marginal benefit, and that it not be given further consideration at this time.

It's not clear to us what exactly one would be seeking to accomplish by 
defining anyListType or anyUnionType.  Our best guess is that the idea
is to make it easier to know which types are list-valued, or union-valued,
by inspection of the type hierarchy.  But the information is present 
already, in the properties of the simple type in question.
Comment 2 Michael Kay 2007-04-20 16:18:46 UTC
>It's not clear to us what exactly one would be seeking to accomplish by defining anyListType or anyUnionType.

Two things, I guess:

(a) QT languages currently provide no access to information about types other than their names and their place in the type hierarchy; so the proposal would provide more information to users of these languages without inventing new mechanisms for access to metadata.

(b) Even if access to metadata properties were available, it wouldn't fall into the type system: one wouldn't be able to define a match pattern in XSLT that matches all list-valued attributes.

But the comment was phrased more as something to consider in order to maintain symmetry and tidiness in the type hierarchy given that anyAtomicType is being added at the same time. There won't be any push-back if it's dropped.
Comment 3 David Ezell 2007-08-24 15:48:06 UTC
Telcon discussion.  The WG still thinks that while this may make the REC more complete, it will be fairly disruptive at this point.

We request that you either allow us to close this issue or else let us know other feelings.

Comment 4 David Ezell 2007-08-24 21:01:11 UTC
(sorry, should have added this to the previous comment...)

Please let us know if you agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.