datatype Equality

(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