- From: Steve Speicher <sspeiche@gmail.com>
- Date: Mon, 23 Sep 2013 19:53:31 -0400
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7Jppu0eGuUCfTu0E6+8PC_prUXr7q-f43bzmCyQuwuRWQQ@mail.gmail.com>
Zat does make sense, what I thought but I couldn't conclude how "last" implied doubly-linked (so you confirmed it doesn't, just extra features that RFC5988 provides) - Steve Speicher On Mon, Sep 23, 2013 at 6:27 PM, Eric Prud'hommeaux <eric@w3.org> wrote: > * Steve Speicher <sspeiche@gmail.com> [2013-09-23 14:53-0400] > > 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"? > > My proposal is intended to cover two cases, the original expressivity > of the navigation data that was in the RDF payload (which I would > describe as being navigated like a singly-linked list) and a more > expressive "doubly-linked" mode which delivers both the head and tail: > Link: <resourceURL>?firstPage; rel="first" > Link: <resourceURL>?page2; rel="last" > > I expect that many applications will benefit from being able to skip > to the end, and RFC5988 already provided the vocabulary, so it seemed > like a pretty natural feature. I'm not a big fan of optional features, > but since back-traversal wasn't in the original langauge, I didn't > feel entitled to add it when migrating to HTTP headers. Also the > singly-linked server could be implemented with static content, unaware > of what had been appended to the end of the list, and I didn't want to > take away that feature. Zat make sense? > > > > - 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 > > > > > > > > -- > -ericP >
Received on Monday, 23 September 2013 23:53:59 UTC