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 17477 - [DM 3.0] Definitions of xs:untyped, etc
Summary: [DM 3.0] Definitions of xs:untyped, etc
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2012-06-13 08:00 UTC by Michael Kay
Modified: 2012-07-17 14:39 UTC (History)
0 users

See Also:


Description Michael Kay 2012-06-13 08:00:52 UTC
In section 2.7.2 of XDM we give a brief definition of the types xs:untyped, xs:untypedAtomic, and xs:anyAtomicType.

At the end of the section we say "A schema for these types is provided in C Schema for the Extended XS Namespace."; however, this only applies to the last two types listed (xs:dayTimeDuration and xs:yearMonthDuration).

We should say that when the implementation supports XSD 1.1, the XSD 1.1 definitions of the types xs:anyAtomicType, xs:dayTimeDuration, and xs:yearMonthDuration supersede those in the XDM specification.

We should also say a little more about the types xs:untyped and xs:untypedAtomic. For example, the specification of deep-equal() depends on knowing whether these types are simple or complex, and if complex, what their variety is. (I imagine xs:untyped is a complex type with mixed content, but I don't see anything that says this explicitly). Ideally we should give a property tableau for these types in the same style as XSD (see for example Or perhaps we could say that the properties of xs:untyped are the same as those of xs:anyType, except for the base type and the name.

Finally, we say "No predefined types are derived from xs:untyped.", and the same for xs:untypedAtomic. I think we should also say that no user-defined types can be derived from these types. (It's fairly obvious that we provide no mechanism to derive user-defined types from these built-in types, but some implementors provide programmatic ways to construct new types and for completeness we should ban this, as the semantics are not well defined.)

XSD 1.1 prohibits derivation from xs:anyAtomicType by restriction, union, or list, and we should do likewise for implementations using XSD 1.0.
Comment 1 Norman Walsh 2012-07-17 14:21:21 UTC
I've attempted to address these issues, see

* I clarified that the schema only applies to the duration types.

* I added a statement to the effect that XSD 1.1 definitions take precedence.

* I don't feel competent to provide the tableau for xs:untyped, so I opted for the suggestion that we say it's the same as xs:anyType except for the name and base type.

* I added text to indicate that no derivation from xs:untyped or xs:untypedAtomic is allowed.

* I added the statement that xs:anyAtomictype cannot be extended by restriction, union, or list.
Comment 2 Michael Kay 2012-07-17 14:39:08 UTC
Looks good to me.