This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XQuery 1.0 currently treats xs:anyAtomicType as an abstract type (even though xs:anySimpleType is instantiatable). XSD 1.1 seems to be making it instantiatable. Since I do not see many use cases for having actual instances that are typed xs:anyAtomicType and because of potential future impact on XQuery, I urge you to make the type abstract as well. It is better to be restrictive and loosen the restriction later than be more lenient and providing more complexity.
The XML Schema WG discussed this issue on its telcon of 14 September (see http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2007Sep/0002.html [member-only link] for minutes), but did not reach consensus.
From the above telcon: Straw poll: In favour of changing to abstract: 1 In favour of keeping it concrete: 4 + 2 halves
The preponderance of sentiment was to not make the change because xs:anySimpleType is already concrete and is used in schemas in the wild for generic attributes. If you wish to define a base level schema that has no commitment to a specific type for an attribute, with the intention that later versions or local refinements of that schema will give a specific type, you have no other option. So it is by no means obvious to us that making xs:anySimpleType concrete constitutes a design mistake. Has xs:anyAtomicType been available in XSDL 1.0, likely many of these schemas would have used it in the way xs:anySimpleType is now used, and outlawing this practice seems counter-productive. In addition, while it is quite possible for a type derivation hierarchy in the context of structures to have this kind of flip-flop from concrete to abstract to concrete types, this would be the only case within the datatypes proper, which do get used in other contexts, and this gives (some of) us pause. On the other hand, we do not fully understand that the actual impact on XQuery as a language would be, and would welcome a crisper explanation of that.
Discussed at 2007-10-12 F2F. Resolved: no, anyAtomicType should remain concrete. Rationale: parallelism with anySimpleType and lack of cost in QT, since anyAtomicType is already mapped to untypedAtomic.
To expand the explanation of the decision (unofficially): If xs:anyAtomicType is concrete in XML Schema, then an XDM node can be annotated as having type xs:anyAtomicType. XDM already assumes this situation can arise, and states that when such a node is atomized, the result is an xs:untypedAtomic value. XPath does not allow creation of a free-standing atomic value of type xs:anyAtomicType, so when seen as an "item type" rather than as a "schema type", the type is abstract. But making it abstract as a schema type appears to be unnecessary. There seem to be some use cases for allowing it to be used, for example in: <xs:attribute name="x" type="xs:anyAtomicType"/> Currently xs:anySimpleType is allowed in this situation; the difference between the two cases is that if xs:anyAtomicType is used, then any restricted type can only restrict it to an atomic type, not to a list type. (Mind you, this use case also argues that xs:anyListType would be useful, which contradicts the rationale for another decision...)