On 5/15/2014 4:18 PM, Tim Hudson wrote:
On 16/05/2014 6:05 AM, John Leiseboer wrote:
>
If you are suggesting that the order of objects
returned from Locate should be made to be required to be
deterministic then you should perhaps raise that as a
separate proposal.
No. I am not
suggesting this at all, as this would not solve the issue.
Given the discussion at the last face to face I’m reluctant
to raise much at all. I just wanted to point out, and you
have confirmed, that the proposed solution is not consistent
with the specification, and that it is not robust to
implementation differences (or in other words, it relies on
server implementations being “sensible”, where sensible does
not mean designed in accordance with the specification).
Actually no John - I'm pointing out that the item you are raising
in the context of this issue is an item we have as a technical
committee previously determined did not need to be set as a
requirement. If you want to revisit that issue then you should
raise the base issue independent of the proposal that updates a
feature.
This proposal is entirely consistent with the specification - it
continues to not mandate (or preclude) a specific order.
The specification does not mandate a particular design for a
server (that is a non-goal) - it specifies an interoperability
protocol - server design is left to the implementers of each
server.
Tim.
Maybe I'm being dense (wouldn't be the first time), but one would
assume the purpose of the
offset is to allow someone to iterate through the values in chunks,
but if there's no guaranteed
order, using locate with an offset doesn't mean you'll ever be able
to get the full set of results you may
have been looking for. Guess without ordering I just don't see the
point of this option.
Sue
