W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2013

Re: claimed completion of ACTION-97 - proposal for pure-HTTP paging

From: Steve Speicher <sspeiche@gmail.com>
Date: Mon, 23 Sep 2013 14:53:03 -0400
Message-ID: <CAOUJ7Jp8VPtNJrOy1vhQQQ4tGcxPOofRBe5prRLs7SPFa_UBww@mail.gmail.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Hey Eric,

+1 but a question below...

On Sat, Sep 21, 2013 at 9:40 PM, Eric Prud'hommeaux <eric@w3.org> wrote:

> Find the <PROPOSAL/> 44 lines down.
>
> TimBL's comment LC-2836 proposed moving page control out of the body
> of an LDPR and into headers.
> <https://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2836?cid=2836>
>
> This buys us:
>    Potential reuse outside of LDPRs.
>    Unrestricted data in an LDPR (screw case: an LDPR which includes a
>     page from another LDPR).
>
> The first example in the LDP LC decribes how a GET on <resourceURL>
> 303's (now 208's?) to e.g. <resourceURL>?firstPage, or OPTIONS on
> <resourceURL> yields:
>   Link: <resourceURL>?firstPage; rel="first"
> The content of <resourceURL>?firstPage includes client data plus this
> paging data:
>
> [[
> <http://example.org/customer-relations?firstPage>
>    a ldp:Page;
>    ldp:pageOf <http://example.org/customer-relations>;
>    ldp:nextPage <http://example.org/customer-relations?p=2>.
> ]] <http://www.w3.org/TR/ldp/#ldpr-PagingIntro> (can we have an anchor
>    on the <div class="example"/> elements?)
>
> The paging in this example is a singly-linked list split across HTTP
> and the payload. We can move it all into HTTP (for the reasons above)
> using link types defined in RFC5988 Web Linking:
>
> first      - An IRI that refers to the furthest preceding resource in a
>              series of resources.
> last       - An IRI that refers to the furthest following resource in a
>              series of resources.
> previous   - Refers to the previous resource in an ordered series of
>              resources
> next       - Refers to the next resource in a ordered series of resources.
>
> The type arc can come from RFC6903 Additional Link Relation Types:
> type      - Refers to a resource identifying the abstract semantic
>             type of which the link's context is considered to be an
>             instance.
>
>
> <PROPOSAL>
>  GETs and OPTIONS on <resourceURL> remain the same.
>
>  GET/HEAD on <resourceURL>?firstPage returns purely user content with:
>     Link: http://www.w3.org/ns/ldp#Page; rel=type
>     Link: <resourceURL>?page2; rel=next
>
>  Lack of a Link: rel=next means you're at the end (closed HTTP world).
>
>  GET/OPTIONS on "doubly-linked servers" return an addtional last linl:
>   Link: <resourceURL>?page2; rel="last"
>

Why does this imply "doubly-linked servers" and why do you call this out
and not "first"?

 - Steve Speicher


>  GET/HEAD on <resourceURL>?page2 on "doubly-linked servers" includes
>     Link: <resourceURL>?firstPage; rel=previous
> </PROPOSAL>
>
>
> I prefer these link types to others in the IANA registry:
> <http://www.iana.org/assignments/link-relations/link-relations.xhtml>
>
> RFC6903 Additional Link Relation Types:
> about      - Refers to a resource that is the subject of the link's
> context.
>
> RFC6573 The Item and Collection Link Relations:
> collection - The target IRI points to a resource which represents the
>              collection resource for the context IRI.
> item       - The target IRI points to a resource that is a member of
>              the collection represented by the context IRI.
>
> POWDER:
> describedBy
> RFC6892 The 'describes' Link Relation Type:
> describes
>
> RFC6906 The 'profile' Link Relation Type:
> profile    - Identifying that a resource representation conforms to
>              a certain profile, without affecting the non-profile
>              semantics of the resource representation.
> --
> -ericP
>
>
Received on Monday, 23 September 2013 18:53:31 UTC

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