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

oops, didn't see this 'till I was looking over the action status.

* John Arwe <> [2013-09-24 16:34-0400]
> Eric, how does your proposal map ldp:pageOf (rule and 
> ldp:containerSortxxx (5.3.2-5.3.5) to headers?
> Despite your stated preference, it appears that pageOf could be addressed 
> using rel=collection.

Hmm, I'm not sure that I even proposed a way to write ldp:pageOf. Yes,
using rel=collection makes perfect sense. Added below:

• GETs and OPTIONS on <resourceURL> remain the same.

• GET/HEAD on <resourceURL>?firstPage returns purely user content with:
    Link:; rel=type
    Link: <resourceURL>?page2; rel=next
    Link: <resourceURL>; rel=collection

• 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

> Container sort criteria are far less obvious however, and was the sticky 
> part when we discussed the proposal at the F2F.  Those currently require 
> the presence of a ldp:Page resource in the triples regardless of whether 
> or not the particular resource supports paging.

Aren't they only in LDPCs? I'm just trying to get the LDP footprint
out of the LDPRs (per TimBL's request, but it also makes sense to me).

> Best Regards, John
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario


Received on Thursday, 26 September 2013 21:16:14 UTC