- From: Jeen Broekstra <jeen@aduna.biz>
- Date: Tue, 03 May 2005 10:42:42 +0200
- To: andy.seaborne@hp.com
- Cc: public-rdf-dawg@w3.org
Seaborne, Andy wrote: >> AFAICT this about covers most specified cases. I've come up with a >> number of other test cases as well (mixed bindings of untyped and >> typed literals, bnodes, etc.), but for most of these the spec does not >> specify a specific ordering. > > > Ordering between mixed items is determined but ordering within them may > not be. > > """ > (Lowest) no value assigned to the variable in this solution. > Blank nodes > URIs > RDF literals > """ Exactly, so it is useless to formulate test cases for these situations as each processor will do it differently anyway. Note that there _are_ test cases for mixed items, but only for those cases where the order is still clearly defined by the spec. Basically the tests are limited to cases where the order is not processor-dependent. > A total ordering isn't appropriate as Pat pointed out - it depends on > what datatypes the processor understands. Even if a processor understood every imaginable datatype a total ordering is still inappropriate or even impossible. Some datatypes are simply not comparable at all. Heck, some datatypes are _themselves_ not (totally) ordered (xsd:dateTime and xsd:duration for example). Related to that, I think the spec is not completely clear on one notion that we might want to be a bit more precise on. Suppose we have two datatyped literals of incomparable types, for example one is a xsd:float and the other a xsd:boolean. The spec says that for such cases order is undefined. Fine. Now suppose we have _two_ floats and a boolean: "1E2"^^xsd:float "1E4"^^xsd:float "true"^^xsd:boolean The spec only says that for incomparable types the result order is not defined. So strictly speaking, the spec not only endorses the above sorting, but also this: "1E2"^^xsd:float "true"^^xsd:boolean "1E4"^^xsd:float This is a rather weird and unnatural way of implementing sorting of course, but strictly speaking legal I think. Do we want to reword to prevent this? Jeen -- Jeen Broekstra Aduna BV Knowledge Engineer Julianaplein 14b, 3817 CS Amersfoort http://aduna.biz The Netherlands tel. +31 33 46599877
Received on Tuesday, 3 May 2005 08:40:42 UTC