- From: Richard Newman <r.newman@reading.ac.uk>
- Date: Mon, 26 Feb 2007 09:55:02 -0800
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: Stephane Fellah <stephanef@imagemattersllc.com>, public-rdf-dawg-comments@w3.org
> Hmm, good point. I can propose to add a short paragraph to 11.3.1: > [[ > Additional mappings of the '<' operator are expected to control the > relative ordering of the operands, specifically, when used in an > <a href=3D"#modOrderBy"><code>ORDER BY</code></a> clause. > ]] I'd agree with that, with an addition (see below). > The problem is that I'm not convinced that they should or should > not affect ordering, or even how much time it's worth delaying the > specification for this. The current spec does not specify total > ordering in part because the use cases didn't motivate us to. Not > every implementor decision that affects the query results need be > specified, only those where interop is useful. I don't really mind either way. If implementations can extend ordering, a note must be added that, in general*, queries featuring LIMIT/OFFSET and ORDER BY are not interoperable. >> You upgrade your =20 >> implementation and your queries start yielding different results. =20 >> That's bad. > > But how bad? We worked hard to avoid this in terms of the collection > of results. I guess changing the order and then slicing means you have > a different answer in your reported collection. The results returned by a query featuring ORDER BY will have an implementation-defined ordering whenever values with datatypes other than string, boolean, datetime, or numeric are compared. Furthermore, the results returned by queries featuring both ORDER BY and LIMIT or OFFSET are entirely implementation-dependent whenever such datatypes are used. This means that the WG's efforts to provide for only extension, not modification, of behavior apply only to the evaluation of a subset of all queries -- those without these characteristics. (Sliced results are already somewhat damaged because there is no total ordering: when a slice point falls in an undefined segment of the results, unexpected behavior can occur. This makes things a little worse, though.) I'd suggest adding some text to the effect of my text above, with the additional advice that ordering expressions can use STR() or another operator to guarantee the type of values to be compared, thus controlling the ordering. Thanks for your reply, Eric. -R * queries without specific efforts made cannot be guaranteed to be interoperable: ORDER BY ?x -- not interoperable, because ?x could be any value, and trigger any implementation of less-than. ORDER BY str(x) -- interoperable, because string< is well-defined.
Received on Monday, 26 February 2007 17:55:19 UTC