Re: [LDP Paging] Comparison to other techniques of pagination

Hi Austin,

Replying for John as he is out for a spell, see below.


On Thu, Oct 2, 2014 at 2:31 AM, Austin William Wright <aaa@bzfx.net> wrote:
>
> On Wed, Sep 17, 2014 at 9:25 AM, John Arwe <johnarwe@us.ibm.com> wrote:
>>
>> Austin, the working group asked me to reply to your comment.  I'm the
>> default RFC monger in this working group ;-)
>>
>>
>> Based on the volume of discussion we've had in the past, which includes
>> within the working group in addition to liasing with other groups such as
>> the W3C TAG and the IETF HTTP working group, such a comparison is highly
>> unlikely to be small enough to non-disruptively fit in the introduction/etc
>> of the document.
>>
>> If you have some alternatives to the reasoning below not covered here,
>> please share as it's conceivably new information that would alter consensus
>> opinions.
>
>
> [snip]
>
> Hi John, thanks for the fantastic response.
>
> Of course, I'm not proposing such a thorough discussion be added in the
> introduction. But mostly I'm curious how this impacts developers like me who
> are already using link=next/prev, and might want to integrate LDP. Or maybe
> more specifically, what functionality this gives implementers, over RFC5005
> by itself.
>
> My understanding is that we can already use RFC5005 pagination for exposing
> documents in a series; but we might want to utilize LDP Paging if we still
> want to refer to a resource -- all the pages together -- as a /single/
> resource or graph, to which we could refer to or perform onperations on
> (like PATCH, as mentioned). Does this sound correct?
>
This sounds correct.

>>
>> wrt adding new Range units, various working group members have looked at
>> it several times over the life of the working group; personally, I did so as
>> far back as Submission-drafting time.  The primary reasons that worked
>> against re-use of Range were:
>>
>> 1: Servers are not free to initiate paging unilaterally using Range
>> requests.  The ability for the server to initiate paging as a way to manage
>> server load (and as a side effect, potential attacks) is a major concern of
>> the working group members.
>
>
> Is LDP Paging able to unilaterally initiate paging? The document says that
> was avoided because it could break existing clients that know a resource to
> already be a cohesive, unpaged representation:
>
> <blockquote> The new protocol does not solve the problem of migrating
> existing clients from the old "all" to the new "first subset" </blockquote>
>
> Or would a new status code be able to initiate paging without any Prefer
> header?
>
No, the server can not initiate paging unless the client indicates it
is prepared to handle it per:

[[ 6.2.6 LDP Paging servers should not initiate paging unless the
client has indicated it understands LDP Paging or that it is prepared
to process 2NN Contents of Related responses ]]

> Also, in my understanding, an ETag varies over representations. Is it
> intentional that the ETag header doesn't change over each page, in the
> listed examples?
It is not intentional, just a copy and paste.  I will update the
examples to not reuse the same etag values for different resource
representations.

> Could it change, especially if that were easier to
> implement in my service? (Though ETag is per-resource, and each page gets
> its own URI, so this is likely a non-issue in general.)

The intent is etags would change as they would normally in your
implementation.  Each page has its own URI and etag, you change the
etag as your resource changes.

> [snip]
>
>>
>> wrt Content-Location and status code, this was an option that members of
>> the working group did discuss with the W3C TAG [2],[3]and the IETF HTTP
>> working group (their chair is cc'd on [3], as one example); short answer,
>> there was no broad consensus on whether or not doing what you suggest is
>> within HTTP, nor (if it is) that HTTP supplies an unambiguous and
>> semantically correct interpretation.
>>
>> 1: [4] says that in the case you describe the C-L URI identifies a
>> particular representation of the effective request URI.  The LDP established
>> consensus that a single in-sequence page, in the general case, is not *the
>> same resource* (in the sense of "state") as the paged resource.  We did not
>> have consensus that the definition cited allows the server to respond to GET
>> paged-resource-URI with 200 and C-L that identifies an in-sequence page
>> (which, definitionally, has only a subset of the paged resource's state); my
>> sense is that the working group mostly found that interpretation unnatural.
>> A client receiving a 200 response was believed to have every right to stop
>> there (at that first GET), believing it has the *entire* state of the paged
>> resource; this would not be true however when a paged resource is identified
>> by the effective request URI and an in-sequence page resource is identified
>> by the Content-Location response header (in the general case of the paged
>> resource having > 1 page).
>>
>> 2: There is a competing mindset that says the server says what is, so 200
>> + C-L of a "subset" resource is perfectly fine: clients have to know
>> something about the resource they're asking for.
>>
>> LDP chose to specify an approach that leaves no risk of an existing client
>> incorrectly believing that it has a complete representation of the state of
>> the resource identified by the effective request URI when it does not, given
>> existing implementations.  If consensus evolves in the wider community over
>> time, then LDP Paging might be able to incorporate whatever optimizations
>> become enabled, but the currently specified base should continue to work
>> unchanged, even if it has to start with 303 to be safe wrt existing clients.
>> The at-risk text between 6.2.5 and 6.2.6 contains additional links as well.
>
>
> So, how is an LDP Paging response different than Content-Type Negotiation,
> such that 2xx (Contents of Related) becomes necessary?
>
The difference is that clients doesn't know they are getting a subset
of the full paged resource (per John's summary above).

> Is the difference that we already have an information resource at
> <http://example.org/customer-relations> and we want to serve a _different_
> information resource? This seems to be TBL's original example for
> pagination, though I don't see any reason this is much different than
> Content Negotiation.
I guess it matters in how much your clients can determine from the
existing headers and content whether it received "the" paged resource
or a "subset" of it.

> [snip]
>
>>
>> wrt scope of applicability
>>
>> Indeed, we separated Paging out in part to allow its application
>> independently of LDP proper.  Along the way, the language was changed so
>> that it applies to more than just RDF based resources.
>> Are there any particular aspects of LDP that you believe your server would
>> not comply with, or is the definitional normative requirement on being an
>> LDP server coupled with the size of the LDP spec simply leading you to
>> assume that you're not compliant?  The bare-minimum difference between a
>> compliant LDP server and a conforming HTTP server is pretty small, IIRC -
>> skimming it's 4.2.1.3 etags, 4.2.1.5 default base URI, done (assuming you
>> don't intend to expose LDPRs or LDPCs, but we're talking about bare-min) .
>> LDP, for example, does not require you to host RDF at all or to deal with
>> containers at all.  If your question stems in part from a "follow your nose
>> - oh, a different big scary spec I have to grep through in order to use
>> Paging at all, how 'nice'" reaction, that is something we could clarify in
>> principle.
>>
>> As to other groups, as mentioned above we've engaged directly with the TAG
>> and IETF HTTP on certain aspects, as well as co-membership with the RDF
>> working group, and we've received comments on past LDP LC drafts (which did
>> include Paging at first) announced the usual way over the span of a year
>> from a variety of sources including Tim Berners-Lee.  If there are specific
>> communities you have in mind to solicit that we might have omitted, this is
>> a perfect time to get them reading and we'd appreciate your help in
>> motivating them to comment within the review period.
>>
>
> Particularly I was wondering if this could be applied to more generic,
> not-necessarily-LDP uses like a photo gallery, product catalog, or list of
> blog posts (though such usages would be prime candidates for LDP). It
> appears this might be covered by `max-member-count`, but I'm not sure
> because "member" is not well defined. Can a "member" be... anything? (I
> would expect a term like "item" to be used for this purpose, as in "list
> item".) This is probably the only thing that really needs clarification.
>

"member" is intended to be definition from LDP
https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html#dfn-membership-triples
We could include a reference to the definition to help clarify things.

I wonder in your non-LDP cases if RFC5005 has  enough of what you
need.  The question I'd have, what are the compelling features from
LDP-Paging that you would like to apply more broadly?

Thanks for the feedback,
Steve Speicher

>
> Thanks again,
>
> Austin.

Received on Monday, 6 October 2014 12:56:44 UTC