- From: C.M.Sperberg-McQueen <cmsmcq@acm.org>
- Date: Fri, 4 Jul 2008 10:29:53 -0600
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>, Dave Peterson <davep@iit.edu>, www-xml-schema-comments@w3.org, OWL Working Group WG <public-owl-wg@w3.org>
On 4 Jul 2008, at 09:13 , Alan Ruttenberg wrote:
> On Jul 4, 2008, at 11:10 AM, C. M. Sperberg-McQueen wrote:
>> Personally, I thought the spec was fairly clear that the
>> disjointness of the primitives is a given for purposes of XSD, and
>> is not intended as a constraint on other systems, which will of
>> course wish to compare values across primitive types.
> Apparently not. The OWL Working group is distinctly under the
> impression that this was not the case. And not surprisingly, as one
> thinks of "values" as the things one compares, and these are
> disjoint.
> Would you mind pointing us to the text that makes this clear? It
> would be very helpful for our discussion.
In section 2.5.2, XSD 1.0 says
Note: A datatype which is ˇprimitiveˇ in this specification need
not be a "primitive" datatype in any programming language used to
implement this specification. Likewise, a datatype which is
ˇderivedˇ in this specification need not be a "derived" datatype
in any programming language used to implement this specification.
which I take to be a signal that the spec recognizes that the
derivation relations it describes (and hence also the incomparability
it prescribes for primitives) for its types are features relevant to
XSD, not necessarily to other similar types defined or used elsewhere.
(Of course, this note is talking specifically about implementations of
the types, not other uses of hte types; it's less clear than I
remembered. Perhaps the WG working on 1.0 had lost its belief in the
proposition that other specs would use the XSD datatypes.)
XSD 1.1 is, perhaps, a bit more explicit. In section 2.2.1, XSD 1.1
says
In the identity relation defined herein, values from different
ˇprimitiveˇ datatypes' ˇvalue spacesˇ are made artificially
distinct if they might otherwise be considered identical. For
example, there is a number two in the decimal datatype and a
number two in the float datatype. In the identity relation
defined herein, these two values are considered distinct. Other
applications making use of these datatypes may choose to consider
values such as these identical, but for the view of ˇprimitiveˇ
datatypes' ˇvalue spacesˇ used herein, they are distinct.
WARNING: Care must be taken when identifying values across
distinct primitive datatypes. The ˇliteralsˇ '0.1' and
'0.10000000009' map to the same value in float (neither 0.1 nor
0.10000000009 is in the value space, and each literal is mapped to
the nearest value, namely 0.100000001490116119384765625), but map
to distinct values in decimal.
The use of the word "artificially", and the caution about identifying
values across primitives, both suggest (to me, at least) that outside
the context of XSD validation, cross-primitive comparison is not
logically impossible or meaningless.
In section 2.2.3, XSD 1.1 spec says
For purposes of this specification, the value spaces of primitive
datatypes are disjoint, even in cases where the abstractions they
represent might be thought of as having values in common. In the
order relations defined in this specification, values from
different value spaces are ˇ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.
I think the best say to define the meaning of comparisons on different
primitive datatypes is to follow the rules set out in the XPath 2.0
Functions and Operators spec.
I hope this helps.
--CMSMcQ
Received on Friday, 4 July 2008 16:30:31 UTC