This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 http://www.w3.org/TR/xmlschema11-1/#builtin-ctd). 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.
I've attempted to address these issues, see https://www.w3.org/XML/Group/qtspecs/specifications/xpath-datamodel-30/html/Overview-diff.html#types-predefined * 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.
Looks good to me.