Re: paging in editor's draft

hello john.

On 2013-11-04, 06:09 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>>>>> to me, the whole idea that there is some "natural order" to a
>> >>> collection leads to all kinds of false assumptions. a collection is
>>a set
>I think we are talking about subtly different things here.
>My original statement was
>> I do think it somewhat likely that servers are likely to have some
>> "natural order" that they expect clients to traverse in, probably
>> specific to the resource and/or its type; to some degree this aligns
>That is a statement about server optimizations, not client interface.
>Server implementations optimize for the expected client interactions.
>General clients cannot depend on it in the absence of other information,
>and LDP today is mostly
> silent about what the other information is; the exception is sorting,
>but that is still "weak" information.
>It's a wee bit odd to disclaim all notion of order; even 5005 talks about
>this in section 3.  If the link relation names (first, next, previous,
>last) aren't suggestive enough of a natural order, their descriptions
>repeatedly refer to 'a
> series of documents'.  Its few two paragraphs warn about reading too
>much into them, granted.

without going into too much high-level discussion: all i wanted to say is
that collections don't *need* to have some order, but certainly some
ordering is required to serve them in pages. in feed-land, the implicit
assumption (never specified, and actually not required, but still
something that's implicit to many scenario and uses) is that entries are
sorted by created/updated timestamp.

>LDP sorting only describes the relationship between (sub)sets (wrt the
>entire collection) of members on *different* pages, it does not say
>anything about the order of members on a single page (nor would saying
>that really make much sense
> when dealing with RDF).

not sure why that wouldn't make much sense. wouldn't it actually make a
lot of sense, if i am building a UI that tried to list 100 entries, i can
get sorted pages of 10, but then i have no idea how the 10 are sorted on
each page? sequences are not such a great thing to express in RDF, but
it's possible, and it seems to me that sorted pages may be a more useful
thing to serve than unsorted ones. at least this is definitely the case in
feed-land: if a server would randomly order entries in feed pages, that
would be considered rather unhelpful for many scenarios.

>LDP gives servers a way to expose the sort order that was used (that
>"influenced" the allocation of member triples to pages, if you prefer),
>based on the collection as it existed at a point in time.  A client will
>not be able to retrieve
> another page until it has received a response to some earlier retrieval
>request (that's the only way it finds out the other page URLs), so (by
>definition) clients will access pages at different points in time and
>therefore (absent some additional out of band
> information) they can't make any strong assumptions about the
>"collection as a whole".

yup, and we talked about that earlier. there certainly is no guaranteed
way to see everything, i absolutely agree. but at least it would be nice
to be able to page, and then use those pages to create sorted UI
representations.

>Could certain *server implementations* make stronger guarantees, along
>the lines of what database folks call cursors?  Sure.  Is LDP currently
>attempting to require cursor-like behaviors?  No (not intentionally, at
>any rate).

and i think that's good, because cursors are rather expensive.

>I've had people building internal protocols with stronger guarantees than
>LDP has - at least they tried it.  They found their "general" client
>quickly imploded under its own assumptions once it had to deal with more
>than one server implementation,
> and once they re-oriented their thinking that this is a distributed
>system with asynch requests they were much happier.  They had a bit more
>to deal with on the client side, and they had to just cope with not being
>able to remove certain timing windows "upstream", but they got over it.

and i think we absolutely agree about all of this. so in the end, i think
all i wanted to say is that assuming that a collection is "inherently
ordered" is maybe not such a great idea. it makes sense to support
ordering, because many collections are ordered, and some interaction
patterns (such as paging) simply require *some* sequencing. but still,
that can be random, or there can be a variety of orderings, so there
should be no assumption of "a natural collection sequence" which then
would be used to "insert entries between others". that was all i wanted to
say, but i think we're in violent agreement about this anyway.

cheers,

dret.

Received on Monday, 4 November 2013 22:50:57 UTC