This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT approved comment: In 2.2.3, this sentence is unhelpful: "The value spaces of primitive datatypes are abstractions, which may have values in common". It's much better to state unambiguously that the value spaces are disjoint. (I think what the writer is getting at here is that, for example, an octet sequence consisting of two xFF octets can appear in both the hexBinary and base64Binary data types. But it's muddying the waters to say that the two datatypes have values in common, when in fact the formal model is that they don't: what you might think of as being the same value is actually two different and totally unrelated values.)
(In reply to comment #0) Agreed. This needs rewriting.
I agree that the paragraph could be improved. Here is a proposal; the XML Schema WG has not acted on this yet, but comments are welcome from the QT working group (or Michael Kay as their representative) or other readers. I propose to revise the penultimate paragraph of 2.2.3, which currently reade The value spaces of primitive datatypes are abstractions, which may have values in common. In the order relation defined herein, these value spaces are made artificially ·incomparable·. For example, the numbers two and three are values in both the precisionDecimal datatype and the float datatype. In the order relation defined herein, two in the decimal datatype and three in the float datatype are incomparable values. Other applications making use of these datatypes may choose to consider values such as these comparable. by doing three things: (1) replace the first two sentences, (2) replace "herein" with "here", and (3) rephrase the example so that it's (a) correct and (b) a little easier to follow. The result reads For purposes of this specification, the value spaces of the primitive datatypes are disjoint, even in cases where the abstractions they represent might be thought of as having values in common. In the order relation defined in this specification, values from different value spaces are thus ·incomparable·. For example, the numbers two and three are values in both the decimal datatype and the float datatype. In the order relation defined here, the two in the decimal datatype is not less than the three in the float datatype; the two values are incomparable. Other applications making use of these datatypes may choose to consider values such as these comparable.
Yes, this is a great improvement.
Approved by the WG; awaiting incorporation into the status quo document.
(In reply to comment #2) > I agree that the paragraph could be improved. Here is a proposal; the > XML Schema WG has not acted on this yet, but comments are welcome from > the QT working group (or Michael Kay as their representative) or other > readers. I propose to revise the penultimate paragraph of 2.2.3, > by doing three things: > (2) replace "herein" with "here", > The result reads > In the order relation defined here, the two in the decimal Just noticed this while implementing the change in the master .xml document: "Herein" is correct, since that means "somewhere in this document", while "here" is not, since that means at this place in the document. However, since that nuance will go over the heads of most readers, and those who understand will get past it, I won't propose fixing it. (The earlier "herein" was changed to "in this specification", which is what "herein" means in this document, so no problem there.)
The change proposed above was approved by the WG in its call of 17 November 2006. It is now reflected in the status quo version of the Datatypes spec. Accordingly, I am setting the disposition of this issue to RESOLVED / FIXED. If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. To signal that the resolution is acceptable, change the status of the issue to CLOSED. Otherwise, to signal that it's NOT acceptable, change the status to REOPENED (and tell us what's wrong). If we don't hear from you in the next three weeks, we'll assume that silence betokens consent, and close the issue ourselves.
>If the originator of the issue would examine the change and let us know whether it satisfactorily resolves the problem or not, we'd be grateful. As a matter of process, this and other comments were raised on behalf of QT. I think it would be useful if I prepare a summary of the status of all these comments (with recommendations for acceptance or non-acceptance) for review perhaps in joint session at the Seattle meeting.