--- a/ldp-paging.html Mon Apr 21 08:38:28 2014 -0400
+++ b/ldp-paging.html Mon Apr 21 08:55:42 2014 -0400
@@ -272,7 +272,7 @@
<dd>A link to the next <a title="Single-page resource">single-page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
- header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
+ header [[!RFC5988]][[!HTML5]] where the target URI is <var>P<sub>i=2...n</sub></var>.
<p></p></dd>
<dt><dfn>last page link</dfn></dt>
@@ -286,7 +286,7 @@
<dd>A link to the previous <a title="Single-page resource">single-page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
- header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
+ header [[!RFC5988]][[!HTML5]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
<p></p></dd>
</dl>
@@ -301,7 +301,7 @@
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
- @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.</pre>
+ </pre>
</section>
</section>
@@ -321,10 +321,10 @@
<li>B.2 Non-normative references: <b>non-normative</b></li>
</ul>
-<p>A conforming <b><dfn>LDP Paging client</dfn></b> is a conforming LDP client [[!LDP]] that follows the rules defined by LDP.
+<p>A conforming <b><dfn>LDP Paging client</dfn></b> is a conforming LDP client [[!LDP]] that follows the rules defined by LDP Paging.
</p>
-<p>A conforming <b><dfn>LDP Paging server</dfn></b> is a conforming LDP server [[!LDP]] that follows the rules defined by LDP.</p>
+<p>A conforming <b><dfn>LDP Paging server</dfn></b> is a conforming LDP server [[!LDP]] that follows the rules defined by LDP Paging.</p>
</section>
<section id="ldppclient">
@@ -347,6 +347,7 @@
<section class="informative" id="ldpr-informative">
<h2>Introduction</h2>
+<!-- TODO: Rewrite intro -->
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
that conform to the simple patterns and conventions in this section.
HTTP requests to access, modify, create or delete LDPRs are accepted
@@ -356,7 +357,7 @@
<p>Some of the rules defined in this document provide
clarification and refinement of the base Linked Data rules [[LINKED-DATA]];
others address additional needs.</p>
- <p>The following sections define the conformance rules for LDP servers when serving LDPRs.
+ <p>The following sections define the conformance rules for LDP Paging servers when serving LDP-RSs.
This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RS's representation</a> if it gets too big.
Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.
</p>
@@ -373,15 +374,17 @@
single HTTP response.
To address this problem, servers should support a technique called Paging.
When a client retrieves such a resource, the server redirects the client to a "first page" resource, and includes in its response
- a link to the next part of the resource's state, all at a URLs of the server's choosing.
+ a link to the next part of the resource's state, all at URLs of the server's choosing.
The triples in the representation of the <a title="Single-page resource">each page of an LDPR</a>
are typically a subset of the triples from the <a title="Paged resource">paged resource</a>.
</p>
<p><a title="LDP server">LDP servers</a> may respond to requests for a
+<!-- TODO: LDP servers => LDP paging servers, throughout -->
resource by redirecting to the first page of the resource and, with that, returning
a <code>Link <next-page-URL>;type='next'</code> header containing the URL for the next page.
Clients inspect each response for the link header to see if additional pages
are available; paging does not affect the choice of HTTP status code.
+<!-- TODO: Search/remove lossy -->
Note that paging is lossy, as described in [[RFC5005]], and so (as stated there)
clients should not make any assumptions about a set of pages being a complete or
coherent snapshot of a resource's state.</p>
@@ -391,7 +394,7 @@
we’ll split the response across two pages.
The client
retrieves <code>http://example.org/customer-relations</code>, and
- the server responds with <a href="#atrisk-333">status code <code>333 (Returning Related)</code></a>,
+ the server responds with <a href="#atrisk-333">status code <code>333 Returning Related</code></a>,
a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header,
and the following representation:
</p>
@@ -429,7 +432,7 @@
<p>
Because the server includes a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
- response header, and the status code is 3xx (<code>333 (Returning Related)</code> in this case),
+ response header, and the status code is 3xx (<code>333 Returning Related</code> in this case),
the client knows that more data exists and where to find it.
The server determines the size of the pages using application specific methods not defined
within this specificiation. The next page link's target URI is also
@@ -438,7 +441,7 @@
<p>
The following example is the result of retrieving
the next page;
- the server responds with status code <code>200 (OK)</code> and the following representation:
+ the server responds with status code <code>200 OK</code> and the following representation:
</p>
<pre class="example" id="ldpc-ex-page2"># The following is the representation of
@@ -577,7 +580,7 @@
</p></li>
<li><p>
For the purposes of drafting this section, we assume that the
- new code's value is <code>333 (Returning Related)</code>,
+ new code's value is <code>333 Returning Related</code>,
<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions,</a>
and its definition is given by
<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>, with the substitution of 333 for 2xx.
@@ -596,7 +599,7 @@
</div>
<section id="ldpr-status-code"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD respond
- with HTTP status code <code>333 (Returning Related)</code>
+ with HTTP status code <code>333 Returning Related</code>
to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a>
as the <code>Request-URI</code>, although any appropriate code MAY be used.
</h2></section>
@@ -626,13 +629,13 @@
<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
<p>
There are many cases where an ordering of the members of the
- container is important. LDPC does not provide any particular support
+ container is important. LDP does not provide any particular support
for server ordering of members in containers, because any client can
order the members in any way it chooses based on the value of any
available property of the members. In the example below, the value of
the <code>o:value</code> predicate is present for each
member, so the client can easily order the members according to the
- value of that property. In this way, LDPC avoids the use of RDF
+ value of that property. In this way, LDP avoids the use of RDF
constructs like Seq and List for expressing order.
</p>
<p>
@@ -640,7 +643,7 @@
paginated. If the server does not respect ordering when constructing
pages, the client would be forced to retrieve all pages before
sorting the members, which would defeat the purpose of pagination.
- In cases where ordering is important, an LDPC server exposes all the
+ In cases where ordering is important, an LDP server exposes all the
members on a page with the proper sort order with relation to all
members on the next and previous pages.
When the sort is ascending, all the members on a current page have a