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

+1 from me as well

  Pa
Le 23 sept. 2013 17:59, "David Wood" <david@3roundstones.com> a écrit :

> +1
>
> Regards,
> Dave
> --
> http://about.me/david_wood
>
>
>
> On Sep 21, 2013, at 21:40, 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"
> >
> > • 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
> >
>
>