- 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:32 UTC