- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 26 Nov 2002 16:22:24 +0100
- To: <www-xml-schema-comments@w3.org>
(the big one!) (noting E2-30) http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Sep/att-0057/01-Er rataR-151.html The original text says: Note that a consequence of the above is that, given ·value space· A and ·value space· B where A and B are not related by ·restriction· or ·union·, for every pair of values a from A and b from B, a != b. Given that the earlier text is clear that: A ·value space· is "the set of values". That [Definition:] Atomic datatypes are those having values which are regarded by this specification as being indivisible. That The basic ·value space· of double consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970, inclusive. That The ·value space· of decimal is the set of the values i × 10^-n, where i and n are integers such that n >= 0. We can substitute "double" for A, "decimal" for B, and 1 (the first positive integer) for both a and b and see that we should: Note that a consequence of the above is that, given [the] ·value space· of double and [the] ·value space· of decimal where double and decimal are not related by ·restriction· or ·union·, for [the] pair of values 1 from double and 1 from decimal, 1 != 1. The phrase at the end suggests that this note should not be taken at face value, but in fact serves to show that the "equality" being talked about is misnamed. It appears to be a type-specific equality between two pairs rather than between two indivisable values. This note could perhaps be rephrased to suggest that 1 when regarded as a double is not type-equal to 1 when regarded as a decimal. As it is, it is simply in error. The correction in E2-30 makes the matter worse, by turning the error from being in a non-normative note that fails to clarify the other text, into a normative (but false) assertion: "The value spaces of the primitive datatypes are disjoint (they do not share any values)." This seems to reflect a tension between the declarative body of the datatypes work, and the equal facet which appears to be motivated by the need to support some processing in [XML Schema Structures]. From section 3.11.1 "The comparison between keyref {fields} and key or unique {fields} is by value equality, not by string equality." A possible change, which would reduce possible confusion with mathematical equality is to rename the equality function in both places, to something like "typed-equality" which would compare two pairs; each pair being a datatype and a value from its value space. These would compare equal if the two values compared equal and the two datatypes were both derived from the same primitive type. A further problematic example from the text is the definition of the value space of NOTATION. The ·value space· of NOTATION is the set QNames. This flatly contradicts the assertion that the value spaces are disjoint. === Hmmm ... one way is to rename the equality function and to make it clear that the types of the objects are involved in this function. Another way would be to go back on the values being the atomic indivisible mathematical objects, and say that the primitive type is inherent within the object (i.e. that XSD values are pairs [primitive-type, mathematical-value]). Jeremy
Received on Tuesday, 26 November 2002 10:22:39 UTC