3378 2006-06-23 09:51:27 +0000 Last Call comment: Please make xs:anyAtomicType abstract 2007-10-14 18:18:07 +0000 1 1 1 Unclassified XML Schema Datatypes: XSD Part 2 1.1 only PC Windows XP RESOLVED WONTFIX important, hard P2 normal --- 1 mrys cmsmcq www-xml-schema-comments oldest_to_newest 10209 0 mrys 2006-06-23 09:51:27 +0000 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. 16628 1 cmsmcq 2007-09-17 18:36:09 +0000 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. 16712 2 David_E3 2007-09-20 16:27:46 +0000 From the above telcon: Straw poll: In favour of changing to abstract: 1 In favour of keeping it concrete: 4 + 2 halves 16857 3 holstege 2007-09-28 15:32:05 +0000 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. 17183 4 sandygao 2007-10-14 17:46:32 +0000 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. 17187 5 mike 2007-10-14 18:18:07 +0000 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...)