This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
2.6.2, xdt:anyAtomicType xdt:anyAtomicType "is derived from" xs:anySimpleType, but how? Trivial restriction? And if xs:string (etc) is derived from xdt:anyAtomicType, does that mean its {base type definition} is no longer xs:anySimpleType? After discussion with Henry Thompson, we considered the theory that the type system in the Data Model is not the Schema type system, but an almost isomorphic one that uses the same names. If this is the case, it should be made clearer. (Perhaps it is in the formal semantics.)
FYI: Minutes of discussion from May 2005: > > d) 1295 nor Data Mod [DM] (from XML Core WG) Relation of DM types to > Schema types " 2.6.2, xdt:anyAtomicType xdt:anyAtomicType "is derived from" xs:anySimpleType, but how? Trivial restriction? And if xs:string (etc) is derived from xdt:anyAtomicType, does that mean its {base type definition} is no longer xs:anySimpleType? ... we considered the theory that the type system in the Data Model is not the Schema type system, but an almost isomorphic one that uses the same names. If this is the case, it should be made clearer. (Perhaps it is in the formal semantics.)" MR: Yes, defined in the formal semantics. MSMQ: This is a plea for more honesty about the relationship between the QT and Schema type systems. Proposal: Change from "derived from simple type" to "subtype of simple type". [discussion of whether this really addresses the question] JR: 2.5.4 in XQuery discusses this. Implies that these are as defined in XSD, MSMQ: ...but they are not only defined in XSD 1.1 Don: It's derived by restriction by excluding list and union types. JR: DM 2.6.3 we use different shapes for those that come from XSD. MSMQ: In general, QT's use of restriction and extension is consistent with XSD's. Don's analysis is not based on anything explicit in the documents. [Extensional vs intensional subtypes ???] Karun: There exists a base type in formal semantics Mary: But it's not called {base-type} MR: 2.4.1 XML Schema and the QT type system. MSMQ: Proposes that we go back to asking the editor that we put in wording that xdt:anyAtomicType "is a subtype of" xs:anySimpleType [do we define "subtype" anywhere?] Jim: 8.3.2 in FS MSMQ: Proposal - In section 2.6.2 of Data Model, in the list of predefined types, under anyAtomicType, delete "is derived from" and replace with "is a subtype of." Karun: "is derived from" is used all over XQuery. [more arcane discussion] Jim: Points us back to Michael's proposal. Support? [Various people say yes]. Karun: prefers status quo, but can live with it. JR: wait, I want to see ...[looking at 3.1.4 in datamodel] ... thinks we need to say something about "subtype." Jim: Hearing some resistance ... Norm: Move on, leave open.
The XSL and XML Query WGs propose to resolve this issue by changing the definition of xdt:anyAtomicType in the following way: [Definition: xdt:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic).] Its base type is xs:anySimpleType from which all simple types, including atomic, list, and union types are derived. All primitive atomic types, such as xs:integer and xs:string, have xdt:anyAtomicType as their base type. Please let us know if this satisfies your concerns.
(In reply to comment #2) This still leaves the issue of how XSL/XQuery's version of the schema type system relates to XML Schema's. It seems that these are two separate, but almost identical, type systems.
This apparent discrepancy will be resolved, we anticipate, by the XML Schema 1.1 draft (http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html#anyAtomicType-def [member only]). In the meantime, we observe that the consequences of any discrepancy are mitigated by the fact that the data model doesn't provide any mechanism for a user function to discover the discrepancy. We don't plan to make any changes. Do you find this satisfactory?
(In reply to comment #4) The XML Core group accepts your decision on this.