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

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?


> 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?

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? 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.)

[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?

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.

[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.



Thanks again,

Austin.