paging nomenclature

On 06/23/2014 11:51 AM, Ashok Malhotra wrote:
> The problem with using "segments" or "chapters" is that no one will 
> understand
> what we mean.  "Page"  may be confusing but can be clarified by the 
> context, as in
> "page in a paged resource"
>
> Calling the resource a "paged resource" and then calling what it 
> contains "segments"
> or "chapters" does not seem right.

That's why I said we'd call them "segmented resources" (or "chaptered 
resources" if we use "chapter").

I think there's even an argument for calling what the server does in 
breaking a resource into segments, or segmenting a 
resource,"segmentation".   And then the client can do segment traversal 
or segment walking or something.   (Instead of "paging" referring to 
both what the server does and what the client does.)

I just think clear terminology helps so much in everything down the 
road.  It's not just words in the spec used to explain concepts, it's 
also names of test cases, names of examples, googleable questions and 
answers, and most importantly APIs.    getNextPage could be anything, 
but getNextSegment is crystal clear; isPage could be anything, but 
isSegment is crystal clear, etc, etc.

       -- Sandro

>
> All the best, Ashok
>
> On 6/23/2014 9:32 AM, Sandro Hawke wrote:
>> I took a fresh look at the LDP paging spec [1] this morning, and I 
>> have three main thoughts (and a lot of editorial thoughts which can 
>> wait):
>>
>> 1.  We're not ready to decide on publication today.
>>
>> 2.  On the issue of terminology [2], I'm now thinking that just 
>> changing "single-page resource" will leave something of a mishmash.   
>> It would be much cleaner to have another set of terms which doesn't 
>> overlap with Web Pages.   For example "segment", so we'd have 
>> "segmented resource" and "segment resources" (or just "segments", 
>> less formally).   Or, more fancifully, "chapter", so we'd have 
>> "chaptered resource" and "chapter resources" (or just "chapters", 
>> less formally).
>>
>> If we adopt one of those, we might consider changing the name of the 
>> spec to match (LDP Segments, LDP Chapters), although I can still see 
>> how the whole process could be called "paging", even if you're 
>> "paging through segments" or "paging through chapters".
>>
>> 3.  On the key issue of initiation and interoperability (and thus 
>> conformance), I believe this is our current story, reframed in a way 
>> that makes sense to me:
>>
>>     There are five kinds of LDP clients with respect to paging:
>>
>>     Type 1, the Non-Paging LDP Client.  Ignores first/last/next/prev
>>     headers, ignores 303.  If the server decides a resource is too
>>     big and tries a 303, this client will break.  LDP Spec says
>>     clients SHOULD NOT be like this, but allows them to be like this
>>     and still be conforming LDP Clients.
>>
>>     Type 2, the Silent-Paging LDP Client.  Ignores first/last
>>     headers, but follows a 303 redirect and then follows rel=next
>>     headers, so it works properly if a server initiate paging using a
>>     303.   If servers assume every client is like this, they can do
>>     something like automatic paging for containers with over 1000
>>     members.   But they will be breaking any Type 1 (Non-Paging) clients.
>>
>>     Type 3, the Paging-Acceptable LDP Client.  Follows 303/rel=next
>>     like Type 2, implements 2nn as well, and most importantly sends a
>>     Prefer: page-size header, letting the server know it's safe to
>>     initiate paging with 2nn or 303. (Per IETF, 2nn MUST NOT be used
>>     unless there is reason to believe the client understands it, and
>>     Prefer: page-size is the only way we're defining to give the
>>     server that information).   This type of client can
>>     stream-process resources and intends to fetch all pages, so it
>>     sees no actual benefit from paging.   As such, it might provide a
>>     very large page size, but I suggest we define page-size=unlim for
>>     this case.
>>
>>     Type 4, the Paging-Preferred LDP Client.  Like Paging-Acceptable,
>>     but it can't stream process, or wants just a little bit of the
>>     data, or wants long pauses in streaming, or has some other reason
>>     to have a preference for paging of large resources.  So it sends
>>     an explicit page-size.
>>
>>     Type 5, the Tries-Paging-First LDP Client.   Like
>>     Paging-Preferred, but first tries doing a HEAD, looking for
>>     rel=first or rel=last.  This allows paging from servers that
>>     don't do 303 or 2nn.   Also allows paging in reverse order. Falls
>>     back to doing a GET if those headers are not present.  I suggest
>>     it MUST include the Prefer: page-size header on it's HEAD
>>     request, in case the server only pages upon request.
>>
>> That all seems fairly reasonable.   If complicated.   But I can't see 
>> how to simplify it without breaking things. Personally, I think 
>> everyone should aim for Types 3 and 4, but I see why people might 
>> need 1, 2, and 5.
>>
>> There's a corresponding analysis one could do on the servers, but 
>> it's a little simpler and I'm out of time.
>>
>>         -- Sandro
>>
>>
>> [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html
>> [2] https://www.w3.org/2012/ldp/wiki/Names_in_Paging
>