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

On Fri, Oct 10, 2014 at 8:08 AM, John Arwe <johnarwe@us.ibm.com> wrote:
>
>
> > ... 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.
>
> As currently described, member count depends on LDP - although this is
> overly subtle I agree.  Where it says "This parameter is only meaningful
> for paged containers." we should probably s/containers/LDP containers/
> and/or hyperlink the "containers" definition.  I'll do that.
>
> We did not widely re-examine use cases when we split Paging out of LDP,
> but given people's stated intent to enable wider re-use the WG might be
> amenable to adding such a unit ... more so if you commit to supply an
> implementation report for it.  Otherwise you are free to add your own
> extension unit now and propose it formally in the future, your extension
> simply won't have a standardized definition (and therefore interoperability
> would be limited).  I can't find any place that we explicitly say that,
> although I'm usually careful about those things, so I'll make sure it's
> rendered explicit that extensions unit values are permitted.
>
> Do you want the WG to consider adding a new unit value with the semantic
> you're after (and if so can you commit to implementing it), or treat it as
> an extension?
>
I'm currently in the process of examining what it would take to make the
implementation, in my existing program, and implementing other features of
LDP. I don't foresee widespread deployment of an implementation anytime
soon, however. If desired, I would be willing to make a proof-of-concept
implementation in short order.

One potential problem is that, presently, I default negotiation to a
paged representation, making available a separate URI for the
unpaged/continuous representation (which can't be negotiated into a "first
subset" resource). When it comes to serving Web browsers (and even Web
spiders, who will by definition follow links), this is a sensible default,
but as you mention, not one that we want in general.

Such an extension (for not-necessarily-LDP cases) would primarily be for
the benefit of Web spiders crawling HTML documents otherwise targeted for
Web browsers. It sounds to me like we'd have to reconcile the default
pagination behavior of these two modes (raw semantic data, and structured
data suitable for Web browser consumption). That is, while I already send a
Content-Location and Link headers with paging information when paging is
enabled, when to enable paging is up in the air - Web browsers won't be
sending a header asking to limit the response size, so I have to choose a
sensible default.

My best solution is to set a default based on the selected representation -
assume/imply a reasonable max limit for HTML documents (e.g. "20 blog
posts"), but don't imply a max-* header for other formats like Turtle. I'm
not sure if there's a better alternative, or if it's something that would
need to be addressed at all (defining such specific handling would seem to
fall out of scope).

The changes you applied in response to my previous email look reasonable.

Thanks,

Austin.