Re: more sorting test cases

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