This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have some mixed concepts in 3.2.1 anySimpleType. It begins: "[Definition:] The definition of anySimpleType is a special ·restriction· of anyType. Its ·lexical space· is the set of all sequences of Unicode characters...." 1. The schema component which is the (simple type) definition of the datatype anySimpleType is not the datatype. There is no datatype named 'anyType'. The term referent for "restriction" is the relation defined between datatypes, not schema components. Schema component "restriction" is defined in Part 1, Structures; that is the restriction that should be referenced. (If indeed the STDs should even be mentioned in the definition; they aren't for non-special datatypes even though they could be.) 2. It appears there is no markup for a reference to an externally defined component, although there is for a reference to the properties of an externally defined component. The self-admitted "hack" that causes a datatype reference to anyType to just emit 'anyType' in bold italic, as though it were a special value like absent of positiveInfinity, is misleading. Perhaps we need a format (at least in the hack, if not tied to new markup) that makes it clear which is which. 3. In "its lexical space", the referent of "it" appears to be the STD, but it's the datatype that has a lexical space. We understand when we mean the component and when we mean the datatype, but we should have pity on the newbies that don't yet. Once in a while it makes a difference; to help the newbies realize there is a difference we should never elide the two. (N.B., this doesn't mean we have to belabor the difference--just use the correct terminology/markup for the different cases.)
>We understand when we mean the component and when we mean the datatype, but we should have pity on the newbies that don't yet. You might understand, but I don't, and I don't think you should pity me. If there is anything the reader needs to know about the underlying datatype that they can't find out by looking at the properties of the component, then we need to add something to the component. On the other hand, if the component tells them everything they need to know about the datatype, then by definition we don't need to mention the datatype, we can say everything that needs to be said by reference to the component that describes it. Let's try to make this an engineering specification, not a metaphysical treatise. Components are quite abstract enough without going a layer deeper. Michael Kay
Proposal: 1. To minimally fix this bug: 1.a In the definition, second sentence, change "Its" to "anySimpleType's". 1.b Make the defined-term reference "restriction" in the first sentence point to the definition of "restriction" in Structures (Part 1) rather than the one in this Part. 2. for slightly better markup, change the references to anySimpleType to <term> markup within the definition. 3. For better explanation, remove the redundant description of the value and lexical spaces, and replace it with "All other datatypes are derived from anySimpleType." (In which "derived" is a link to its definition in this (Datatypes, Part 2) spec.) In any case, the same fixes (mutatis mutandis) should be applied to the definition of anyAtomicType.
Resolved: Adopt #1, changing "anySimpleType's" to "The ... of anySimpleType". Adopt #2
The changes agreed upon at yesterday's call have been made in the status-quo version of the spec at http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html (member-only link) Accordingly, I'm marking this issue resolved. Dave, as the originator, it would be helpful if you could close it to indicate your assent, or reopen it to indicate dissent. If we don't hear otherwise from you in the next two weeks, we'll assume you are happy.