Re: [Specifications] Indicate a partial collection view is ordered (#172)

@alien-mcl those are not exclusive approaches. We need both.

> client knows what he asks for and server obeys (this is the one I personally support)

There is not way to enforce that the "server obeys". If the client requests to order by "first name" and "last name" the server has full authority to ignore either or both. The client would want to understand that they got not exactly what they asked for.

Same with a request without explicit order like plain `GET /people`. If the server applied an order the client will not know about it without response metadata.

One more example is implicit order which is more specific than what the client requested. Say the query was `/events?orderBy=year`. The server will do that but to keep a stable order it may implicitly add a second `order by month name` to keep a stable sorting for those items which have the same value for `year`. Otherwise those members would "jump around" their section of the data. Which can produce really weird results when a given number of elements is greater than the page size. Subsequent requests for the same page+order may even return completely different results.

So, the client would want to know that they requested `/events?orderBy=year` but effectively got `/events?orderBy=year,month,name,id`.

----

Too bad you could not join @pietercolpaert. Here are my additional thoughts, some of which have been discussed during the call, some of which have not:

1. We discussed to mandate the use of `rdf:List` when the server decides that it's important for the client. This is the only way which removes the necessity for the client to deeply understand the proposed `hydra:orderedBy` description.
2. Still, I'm convinced that we need this description but it can be simplified when the members are actually an ordered rdf List.

What I mean by the second point is that once the response triples are actually ordered, then the client should not need to know how to actually perform the ordering. Nor should they have to. This completely eliminates the necessity for `castTo` and 

-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/172#issuecomment-553102291 using your GitHub account

Received on Tuesday, 12 November 2019 20:34:47 UTC