W3C home > Mailing lists > Public > public-ldp-wg@w3.org > October 2012

Re: ldp-ISSUE-18 (container membership): container membership and robust pagination [Use Cases and Requirements]

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Fri, 5 Oct 2012 15:40:22 -0400
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
Message-ID: <CC94837E.8ED8%erik.wilde@emc.com>
hello all.

On 2012-10-05 06:53 , "Linked Data Platform Working Group Issue Tracker"
<sysbot+tracker@w3.org> wrote:
>ldp-ISSUE-18 (container membership): container membership and robust
>pagination [Use Cases and Requirements]
>* Should there be a guaranteed way to get the full container membership
>without pagination. ie. Should GET on <containerURL> ''ever'' be
>redirected to the paginated <containerURL>?firstpage ?

from the REST perspective, there should be a URI template associated with
the container URI, which would allow clients to understand that requests
to that resource can be parametrized, and how. how a server would respond
to a request without pagination information (responding with nothing,
everything, or a default of a first page) should probably be left to
decide for implementors of LDP.

>* The current approach to paging is not robust to deletions and
>insertions of container members. Insertions/deletions will have the side
>effect of moving page boundaries. This could be detected by qualifying
>the request with 'If-match'. The ?firstPage still lists the full
>membership so this can be correlated with the results, however, a page
>boundary change makes it hard to recover resources that have 'fallen
>through the cracks.

hm, that sounds odd with respect what you would expect in most pagination
services. pagination almost always is a "view of the current state of the
collection" kind of service, and thus pages are by definition always
subject to change. if you want those view to be stable, you would have to
produce "stable views" (representing the view of a collection at a fixed
point in time) with a dedicated URI and allow pagination over these, but
this is a potentially expensive thing to do, and probably not something
that a lot of services would want to implement.

>* Should the number of resources per page be an explicit property of the

i would make that either server-decided (and exposed in some property), or
part of the service parameters and thus exposed as a URI template

>* Why do we have different query syntaxes for accessing the first and
>subsequent pages (e.g. why not p=1): <URI>?firstpage, <URI>?p=2, ... ?

the important thing are the URI template parameters. how they are mapped
to a concrete URI should be left up to the designer of the URI template,
as long as the service clearly supports pagination parameters. english
servers might call it ?page=42, german ones ?seite=42, but as usual, URIs
always should be completely opaque and the only thing that matters is that
clients can discover the uniform interface (in this case the URI template)
and use it to create a link that works.

>* Is it best to use 'p' or something more descriptive like 'page'?

that definitely should be left to the implementor of a concrete LDP
service. our job is to provide a way how the URI template can contain the
well-defined concept of a page identifier.


Received on Friday, 5 October 2012 19:41:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:32 UTC