--- a/ldp-paging.html Tue Jul 29 13:08:53 2014 -0400
+++ b/ldp-paging.html Tue Jul 29 16:00:27 2014 -0400
@@ -10,6 +10,8 @@
DONE: Missing link header for equivalent of ldp:pageOf? Need to verify. Also we have ldp-paging:pageOf in samples
but it doesn't exist in rules or vocabulary doc, oversight?
+ TODO: Sandro 7/29: loosen up restrictions on target of pageSortCriteria link
+ TODO: Once companion documents (best practices, primer) have URLs, link to them. Search on "companion".
TODO: Mine Jim des Riv May 21 email for more content
TODO: Example 11 is missing ldp:contains, true? Omit due to GET on page resource, should make it more clear.
TODO: Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
@@ -1136,7 +1138,7 @@
<code>307 Temporary Redirect</code> [[!RFC7231]] or <code>308 Permanent Redirect</code> [[!RFC7238]],
as [[RFC7231]] makes clear. This is critical to a client's ability to distinguish between the representation
of a single <a>in-sequence page resource</a> and that of the <a>paged resource</a> when a <a>LDP Paging server</a>
- uses <a href="#ldpr-status-code">redirection</a> as a way to <a href="#ldpr-pagingGET-only-paging-clients">initiate paging</a>.
+ uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
</h2></section>
</section>
@@ -1339,11 +1341,53 @@
</div>
<section id="ldpr-status-code"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> SHOULD respond
- with HTTP status code <code>2NN Contents of Related</code>
- to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a>
- as the <code>Request-URI</code> when the request indicates the client's support for that status code [[!2NN]],
- although any appropriate code such as <code>303 See Other</code> MAY be used.
+ <a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
+ initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
+ process <code>2NN Contents of Related</code> responses [[!2NN]].
+ <a title="LDP Paging server">LDP Paging servers</a> initiating paging SHOULD respond
+ to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a>
+ as the <code>Request-URI</code> in one of the following ways:
+ <ul>
+ <li>
+ If the client supports <code>2NN</code> responses, respond
+ with HTTP status code <code>2NN Contents of Related</code> and the first
+ <a>in-sequence page resource</a>'s representation.
+ </li>
+ <li>
+ If the client supports paging but not <code>2NN</code> responses,
+ respond with
+ status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+ the first <a>in-sequence page resource</a>.
+ The only standard means defined by LDP paging for a client to signal a server that the client
+ understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+ other implementation-specific means could also be used.
+ </li>
+ <li>
+ If the server is willing to provide a non-paged representation, respond
+ with an appropropriate status code (likely <code>200 OK</code>) and the potentially large
+ non-paged representation.
+ </li>
+ <li>
+ Either reject the request, most likely with a <code>4xx</code> status code,
+ or (keeping in mind the note below)
+ initiate paging as described above with a <code>303</code> status code, or
+ choose another status code appropriate to the specific situation.
+ </li>
+ </ul>
+ <blockquote>
+ <em>Non-normative note:</em>
+ <a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
+ available <em>only</em> as a paged resource.
+ In so doing, when interacting with clients <em>unaware</em> of LDP Paging,
+ if the server initiates paging anyway then it runs the risk
+ that an ill-behaved client will automatically follow a
+ <code>303 See Other</code> redirect and believe via the subsequent
+ <code>200 OK</code> that it has obtained a complete representation of the <a>paged resource</a>
+ rather than of a single <a>in-sequence page resource</a>.
+ <a title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+ but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were
+ equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
+ </blockquote>
</h2></section>
<section id="ldpr-guarantee-show-unchanged"><h2 class="normal">
@@ -1514,9 +1558,14 @@
This is one mechanism by which clients know that the resource is one of a sequence of pages.
</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+ <!-- combined into ldpr-status-code
<section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
<a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
- initiate paging unless the client has indicated it understands paging.
+ initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
+ process <code>2NN Contents of Related</code> responses [[!2NN]].
+ If the client supports paging but not <code>2NN</code> responses, a server initiating paging SHOULD respond with
+ status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+ the URI of the first <a>in-sequence page resource</a> of the <a>paged resource</a>.
The only standard means defined by LDP paging for a client to signal a server that the client
understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
other implementation-specific means could also be used.</h2>
@@ -1537,6 +1586,7 @@
equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
</blockquote>
</section>
+ -->
</section>
@@ -1704,13 +1754,13 @@
@base <http://example.org/netWorth/nw1/assetContainer/pageSortOrder/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-<!-- (#SortValueAscending) does not work, because the subject uri would be a blank node -->
+<!-- (#Sort-o.value-Ascending) does not work, because the subject uri would be a blank node -->
<>
a rdf:List;
- rdf:first <#SortValueAscending> ;
+ rdf:first <#Sort-o.value-Ascending> ;
rdf:rest rdf:nil .
-<#SortValueAscending>
+<#Sort-o.value-Ascending>
a ldp:pageSortCriterion;
ldp:pageSortOrder ldp:Ascending;
ldp:pageSortPredicate o:value.
@@ -2088,6 +2138,8 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-07-29 - Fully specify 303+location's URI (JA) </li>
+ <li>2014-07-29 - Fuss with SortValueAscending value for Sandro (JA) </li>
<li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
<li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
<li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>