- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Tue, 03 May 2005 10:55:03 +0100
- To: Jeen Broekstra <jeen@aduna.biz>
- CC: public-rdf-dawg@w3.org
Jeen Broekstra wrote: > 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. Good - but I'm still unclear. It is possible to have a test with one of each kind in the results and get a defined ordering. > > >>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? What wording do you suggest? If it is to cluster things of the same type, I think this gets into problems with subtypes and with processors that do know how to handle them, and also with unknown types over the same value space: Suppose a processor does not know about doubles and floats: clustering gives: "1E2"^^float "1E4"^^float "1E3"^^double But knowing the values gives: "1E2"^^float "1E3"^^double "1E4"^^float > > Jeen Andy One minor thing came up: The data files and some queries still end \r\r\n (after checking out on windows). Doesn't break anything. Have they been checked in UNIX style with \r\n?
Received on Tuesday, 3 May 2005 09:56:04 UTC