Re: Question about number types

At 7:25 PM +0100 2008-07-04, Bijan Parsia wrote:
>On 4 Jul 2008, at 19:06, C. M. Sperberg-McQueen wrote:

>>   It
>>does not lie within the power of the XSD spec, or any other
>>spec, to say that numbers expressible with finite decimal
>>numerals and numbers which can be expressed as m × 2^e cannot
>>be compared.
>
>But that's a slide. Of course you don't say 
>anything like that. But it seems XSD *does* say 
>that xsd:float is disjoint with xsd:decimal. If 
>we use *those types* (which we explicitly do), 
>shouldn't we recognize that aspect of them?

Note that "disjoint" means that values from one primitive datatype are
never *identical with* values from a different primitive datatype.

This whole discussion, however, seems to revolve around whether such
values can be *comparable* (one of a < b, a = b, a > b holds).  Note
carefully that since equality is not identity, we do not require
of our own definitions that every primitive value even be equal to
itself.

It's further true that XSD says that for its purposes, it chooses to
define its equality and order relation in such-and-such a way.  But
it explicitly says that adopters of the datatypes should feel free
to redefine equality and order (among other things) as they see fit.
What more can we say?  It's pretty clear that Alan, for example,
expects a different equality from that chosen by XSLT/XQuery.  We
clearly can't satisfy all users.

>>The disjointness of the value spaces postulated by XSD is a
>>convenient way of handling the relatively few cases of
>>cross-primitive comparison that can arise in schema-validity
>>assessment, and of ensuring that one can postulate, given
>>a value, knowledge of its primitive datatype.
>
>That intention isn't determinable from the spec, 
>so I don't see that you can rely on people 
>treating the disjointness as a mere convenience.

Doesn't really matter.  Do you need identity as well as equality?
Probably not.

>(The comments in the spec about implementation 
>seems, again, to be different from the issue of 
>what is the nature of the type system. I can 
>implement a structural types system in a 
>language with a nominative type system. The 
>question here is what are the right answers from 
>the perspective of the *XSD type system*.)

Granted this is not explicitly stated in the spec:  We don't pretend to
define "complete datatypes".  E.g., we don't define most of the operations
and relations that one would need for decimal, duration (though that's
the one case where a cross-primitive operation is defined:  adding a
duration to a dateTime value), string, or any of the others.  We don't
even say what operations and relations would be appropriate.

The XSD spec defined enough of a datatype that schema processing can be
done, and we suggest (at least by choice of name) what operations and
relations might be appropriate.  We specifically say that adopters of
these XSD datatypes for their own purposes are not even required to
retain unchanged the operations and relations we do define.

If you want to retain them, fine.  If you don't want the ones in the
Spec, you're not obligated to use them.  If you don't want to have
to change the ones in the Spec and don't like them as defined,
speaking for myself, all I can say is "I'm sorry; we weren't able
to please all users--they have incompatible desires."
-- 
Dave Peterson

davep@iit.edu

Received on Friday, 4 July 2008 20:31:08 UTC