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?