Re: review of ldp-paging

> Do you agree with all that?

Yes, modulo this case which appears to violate your Must Not, which I 
don't think is your desired result.
- sorted container
- item falls at the end of the currently-final page
In this case, your options 1 and 2 are talking about the same page and 
saying "may 2" && "must not 1" is incoherent, unless your desired result 
is to always 410 it, which seems (to quote Ashok) "a bit harsh".

> Can you rephrase your question in that framework?   Or say what I'm 
missing?

Since the existing text is written in units=page (not item), I thought 
your option 2 was, or included
2.  Add a new page where it belongs according to the declared sort order.


Maybe adding a new in-sequence page somewhere other than the end should be 
an option, thinking about it yet again.  It's not obviously any worse than 
adding new content to an existing page "in the right place".

I was having an allergic reaction to (what I thought you were saying)
2.  Add a new page where the belongs according to the declared sort order.
but no such reaction to (what you clarified your intent as)
> 2.  Add the new item on the page where it belongs according to the 
> declared sort order.
It seems incoherent for me to be allergic to only one of those two.

The allergen was the idea that the client has no efficient way to figure 
out where the new data landed, which is what I saw as the advantage of 
> 1.  Add the new item at the end.   That is, update the contents of 
> the rel=last page, or start a new rel=last page.
In the absence of that clause, a client has to undertake a fresh traversal 
every time even if the LDPR is an unsorted container.
In the presence of that clause, when the LDPR is an unsorted container a 
client simply retrieves the last page to see if new content was added (and 
etags/next links are "efficient enough" tests on the result).


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead