ldp.html
changeset 497 67f04abb73e6
parent 496 94420c5678ae
child 498 9ab1339e0013
--- a/ldp.html	Tue Feb 18 13:33:42 2014 -0500
+++ b/ldp.html	Tue Feb 18 15:28:39 2014 -0500
@@ -8,13 +8,7 @@
     TODO: Consider how to not have to explicitly list parent classes.
     TODO: Improve LDPC intro by explaining simply that LDP-DC restricts LDPC and LDP-BC restricts LDP-DC.
 	TODO: Add new "discovery of server capabilities" non-norm section
-
-Paging related:
-	TODO: Missing link header for equivalent of ldp:pageOf? Need to verify.
-	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 link	age amongst pages and (HEAD on) the base resource.
-     Maybe also insert HEAD on base as new first example instead of relying on text alone.
-
+    TODO: Missing namespace definition clause?
  -->
 <html>
   <head>
@@ -129,7 +123,16 @@
 					]
 				,   status:   "Proposed Standard"
 				,   publisher:  "IETF"
-				}
+				},
+				"LDP-PAGING": {
+					title:    "Linked Data Platform Paging"
+				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html"
+				,   authors:  [
+						"S. Speicher", "J. Arwe", "A. Malhotra"
+					]
+				,   status:   "Editor's Working Draft"
+				,   publisher:  "W3C"
+				},
 			},
       };
     </script>
@@ -239,11 +242,6 @@
 	A companion document discusses best practices that you 
 	should use, and anti-patterns you should avoid, when constructing these clients and servers.
 	</p> 
-	<p>This specification provides a widely re-usable pattern to deal with large resources.  
-	Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
-	be redirected to a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages 
-	(see <a href="#ldpr-Paging" class="sectionRef"></a>). 
-	</p>
 	<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a 
 	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
 	in building application models involving collections of resources, often homogeneous ones. 
@@ -256,6 +254,8 @@
 	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
 	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
 	implementations will support.</p>
+	<p>This specification provides some approaches to deal with large resources.  An extension to this specification
+	provides the ability to break large resource representations into multiple paged responses [[LDP-PAGING]].</p>
 	<p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [[LDP-UCR]] 
 	and <a href="#base-specs" class="sectionRef"></a>.</p>
 </section>
@@ -386,69 +386,6 @@
 	triples, but if future versions of LDP define additional classes of triples then this definition
 	would expand to subtract out those classes as well.
 	<p></p></dd>
-	
-	<dt><dfn>Paged resource</dfn></dt>
-	<dd>A LDP-RS whose representation may be too large to fit in a single HTTP response, for which an
-	LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Source">LDP-RSs</a>.  
-	When the representations of the sequence's resources
-	are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
-	state.  If a paged resource <var>P</var> is a LDP-RS and is broken into a sequence of pages
-	(single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
-	the representation of each <var>P<sub>i</sub></var> contains
-	a subset of the triples in <var>P</var>.
-	LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>, 
-	but does not specify how clients combine
-	their representations.  See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.  For readers
-	familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
-	Any resource could be considered to be a paged resource consisting of exactly one page, 
-	although there is no known advantage in doing so.
-	<p></p></dd>
-	
-	<dt><dfn>Single-page resource</dfn></dt>
-	<dd>One of a sequence of related <a title="Linked Data Platform RDF Source">LDP-RSs</a>
-	<var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>, 
-	each of which contains a subset of the state
-	of another resource <var>P</var>.  <var>P</var> is called the paged resource.
-	For readers
-	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
-	coherency/completeness considerations apply.
-	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
-	<p>
-	Note: the choice of terms was designed to help authors and readers clearly differentiate between
-	the <a title="Paged resource"><em>resource being paged</em></a>, and the 
-	<a title="Single-page resource"><em>individual page resources</em></a>, 
-	in cases where both are mentioned in
-	close proximity.  
-	<p></p></dd>
-	
-	<dt><dfn>first page link</dfn></dt>
-	<dd>A link to the first <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 &lt;<var>P<sub>1</sub></var>&gt;; rel='first'</code>
-	header [[!RFC5988]].
-	<p></p></dd>
-	
-	<dt><dfn>next page link</dfn></dt>
-	<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 &lt;<var>P<sub>i</sub></var>&gt;; rel='next'</code>
-	header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
-	<p></p></dd>
-	
-	<dt><dfn>last page link</dfn></dt>
-	<dd>A link to the last <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 &lt;<var>P<sub>n</sub></var>&gt;; rel='last'</code>
-	header [[!RFC5988]].
-	<p></p></dd>
-	
-	<dt><dfn>previous page link</dfn></dt>
-	<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 &lt;<var>P<sub>i</sub></var>&gt;; rel='prev'</code>
-	header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
-	<p></p></dd>
-	
   </dl>
 
 <section id="conventions">
@@ -493,7 +430,7 @@
 
 <section id="ldpclient">
 <h1>Linked Data Platform Clients</h1>
-<p>All of the following are conformance rules for <a title="LDP server">LDP Clients</a>.
+<p>All of the following are conformance rules for <a title="LDP client">LDP Clients</a>.
 </p>
 <section><h2>General</h2>
 
@@ -534,6 +471,18 @@
 		be capable of processing responses formed by an LDP server that ignores hints,
 		including LDP-defined hints.
 	</h2></section> 
+
+	
+	<section id="ldpr-cli-paging"><h2 class="normal">
+		
+	<div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
+	<p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+		<a title="LDP client">LDP clients</a> SHOULD 
+		be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+		that independently initiated paged responses [[!LDP-PAGING]]
+	</div></h2>
+	</section> 
+
 	
 </section>
 </section> <!-- Client constraints -->
@@ -574,8 +523,11 @@
 		<li>Are there some typical vocabularies that should be reused?</li>
 	</ul>
 	<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
-		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. 
+	Companion non-normative documents describe additional guidelines for use when interacting with LDPRs. 
+	</p>
+	<p>LDP-RS's representations may be too big, one strategy is to break up the response representation
+	into client consumable chunks called pages. A separate LDP specification outlines the conformance
+	rules around pagination [[LDP-PAGING]].
 	</p>
 	<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state 
 	is represented using RDF (LDP-RS) and those using other formats (LDP-NR).  LDP-RSs have the unique
@@ -617,7 +569,7 @@
 	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
 	
 	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
-		[[!DC-TERMS]], RDF [[!RDF11-CONCEPTS]] and RDF Schema [[!rdf-schema]], whenever
+		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
 		possible.
 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
 	
@@ -662,7 +614,7 @@
 	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
 		of content defined by LDP.  Other specifications built on top of LDP may require clients
-		to implement inferencing [[!RDF11-CONCEPTS]].  The practical implication is that all content defined by LDP
+		to implement inferencing [[!rdf11-concepts]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
 	
@@ -685,16 +637,6 @@
 		document.  Natural language constraint documents are therefore permitted, 
 		although machine-readable ones facilitate better client interactions.
 	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
-	
-	<section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RSs in
-		pages.
-		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
-	</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
-	
-	<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
-		treat any resource (LDP-RS or not) as a <a title="Paged resource">paged resource</a>. 
-		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
-	</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
 
 </section>
 
@@ -869,238 +811,6 @@
 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
 		Method tokens in the HTTP response header <code>Allow</code>.
 	</h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
-		
-</section>
-
-<section id="ldpr-Paging">
-<h2>Paging</h2>
-
-<section class="informative" id="ldpr-PagingIntro">
-
-<h3>Introduction</h3>
-	<p>It sometimes happens that a
-		resource is too large to reasonably transmit its representation in a
-		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.
-		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
-		resource by redirecting to the first page of the resource and, with that, returning 
-		a <code>Link &lt;next-page-URL&gt;;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.
-		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>
-	<p>
-		Looking at an example resource representing Example Co.'s customer
-		relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
-		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>, 
-		a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header,
-		and the following representation:
-	</p>
-
-<pre class="example" id="ldpc-ex-page1"># The following is the representation of
-#    http://example.org/customer-relations?page1
-#    Requests on the URI will result in responses that include the following HTTP header
-#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
-#    This Link header is how clients discover the URI of the next page in sequence,
-#    and that the resource supports paging.
-@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-@base &lt;http://example.org/customer-relations&gt;.
-
-&lt;&gt;
-   a o:CustomerRelations;
-   dcterms:title "The customer information for Example Co.";
-   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 
-
-&lt;#JohnZSmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer;
-   foaf:name "John Z. Smith".
-&lt;#BettyASmith&gt;
-   a foaf:Person;
-   o:status o:PreviousCustomer;
-   foaf:name "Betty A. Smith".
- &lt;#JoanRSmith&gt;
-   a foaf:Person;
-   o:status o:PotentialCustomer;
-   foaf:name "Joan R. Smith".</pre>
-
-	<p>
-		Because the server includes a <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'</code>
-		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
-		defined by the server and not this specification.
-	</p>
-	<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:
-	</p>
-
-<pre class="example" id="ldpc-ex-page2"># The following is the representation of
-#  http://example.org/customer-relations?p=2
-#
-#  There is no "next" Link in the server's response, so this is the final page.
-#
-@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-@base &lt;http://example.org/customer-relations&gt;.
-
-&lt;&gt;
-   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
- 
-&lt;#GlenWSmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer, o:GoldCustomer;
-   foaf:name "Glen W. Smith".
-
-&lt;#AlfredESmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer, o:BronzeCustomer;
-   foaf:name "Alfred E. Smith".
- </pre>
-	<p>
-		In this example, there are only two customers provided in the
-		final page.  To indicate this is the last page, the server omits the <code>Link: rel='next'</code> 
-		header in its response.
-	</p>
-	<p>
-		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
-		that it knows the entire state of the server.  For example, after the server constructs the
-		the first page representation, another
-		actor could delete <code>client#BettyASmith</code> from the server.  
-	</p>
-</section>
-
-<section id="ldpr-PagingGET">
-<h3>HTTP GET</h3>
-	<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, 
-		<a title="LDP server">LDP servers</a> that support paging must 
-		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
-		and their associated <a title="Single-page resource">single-page resources</a>.
-	</p>
-
-	<section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-		add <a title="Single-page resource">single-page resources</a> to a 
-		<a title="Paged resource">paged resource's</a> sequence over time,
-		but SHOULD only add pages to the end of a sequence.
-		</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
-		<blockquote>Non-normative note: 
-		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
-		change as the state of the <a title="Paged resource">paged resource</a> changes.
-		For example, a nominally last page's server might provide a
-		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence crosses server boundaries; 
-		server A might host the initial portion of a sequence that links to the last page server A is aware of,  
-		hosted on server B, and server B might extend the sequence of pages.
-		</blockquote>
-
-		<section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
-			<a title="LDP server">LDP servers</a> MAY provide 
-			a <a>first page link</a> when responding to 
-			requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
-		</h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
-	
-		<section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-			provide a <a>last page link</a>
-			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
-		</h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
-	</section>
-	
-	<section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
-		provide a <a>next page link</a>
-		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
-		<em>other than the final page</em>
-		as the <code>Request-URI</code>.
-		This is the mechanism by which clients can discover the URL of the next page. 
-	</h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
-	
-		<section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
-			provide a <a>next page link</a>
-			in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
-			as the <code>Request-URI</code>.
-			This is the mechanism by which clients can discover the end of the page sequence
-			as currently known by the server.  
-		</h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
-		
-		<section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-			provide a <a>previous page link</a>
-			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
-			<em>other than the first page</em>
-			as the <code>Request-URI</code>.
-			This is one mechanism by which clients can discover the URL of the previous page.  
-		</h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
-		
-		<section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
-			provide a <a>previous page link</a>
-			in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
-			as the <code>Request-URI</code>.
-			This is one mechanism by which clients can discover the beginning of the page sequence
-			as currently known by the server.  
-		</h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
-	</section>
-
-	<section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
-		provide an HTTP <code>Link</code>
-		header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
-		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
-		as the <code>Request-URI</code>.
-		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 -->
-
-	<div class="atrisk" id="atrisk-333"><p class="atrisktext">Feature At Risk</p>
-		<p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
-		<ul>
-		<li><p>
-		A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">TAG discussion</a> has started,
-		whose goal is to reduce the need for two request-response round trips down to one when retrieving what 
-		turns out to be the first page of a paged resource, by defining a new
-		HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
-		respond to <code>GET request-uri</code> requests with the representation of the first page 
-		(whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
-		</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>,
-		<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.
-		Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to 
-		requests for <a title="Paged resource">paged resources</a>.  The only significant difference between 303 and 333 responses
-		is the extra round trip required for the client to retrieve the representation of the first page when using 303.
-		</p></li>
-		<li><p>
-		Once LDP is a
-		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
-		working with the W3C Director, to either use the newly defined response code 
-		as documented in this section or to revert to a classic 
-		<code>303</code> response pattern.
-		</p></li>
-		</ul>
-	</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> 
-		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>
-</section>
 
 </section> <!-- h2 -->
 
@@ -1122,9 +832,9 @@
 	<ol>
 		<li>To which URLs can I POST to create new resources?</li>
 		<li>Where can I GET a list of existing resources?</li>
-		<li>How	is the order of the container entries expressed?</li>
 		<li>How do I get information about the members along with the container?</li>
 		<li>How	can I ensure the resource data is easy to query?</li>
+		<li>How	is the order of the container entries expressed? [[LDP-PAGING]]</li>
 	</ol>
 	<p>
 		This document defines the representation and behavior of containers
@@ -1423,99 +1133,8 @@
 		LDP recommends using PATCH to update these properties, if necessary.  It provides no facility
 		for updating them via PUT without replacing the entire container's state.
 	</p>
-		
 	</section><!-- ldpc-get_empty-container_props -->
 
-	<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
-		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
-		constructs like Seq and List for expressing order.
-	</p>
-	<p>
-		Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
-		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
-		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 
-		sort order no lower than all members on the previous page and 
-		sort order no higher than all the members on the next page; 
-		that is, it proceeds from low to high, but keep in mind that several 
-		consecutive pages might have members whose sort criteria are equal. 
-		When the sort is descending, the opposite order is used. 
-		Since more than one value may be used to sort members, 
-		the LDPC specification allows servers to assert the ordered list
-		of sort criteria used to sort the members, using the 
-		<code>ldp:containerSortCriteria</code> relation.
-		Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>, 
-		consisting of a <code>ldp:containerSortOrder</code>, 
-		<code>ldp:containerSortPredicate</code>, and 
-		optionally a <code>ldp:containerSortCollation</code>.
-	</p>
-	<p>Here is an example container described
-		previously, with representation for ordering of the assets:</p>
-<pre class="example" id="ldpc-ex-ordering">
-# The following is the ordered representation of
-#   http://example.org/netWorth/nw1/assetContainer/
-<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-
-&lt;&gt;
-   a ldp:Container, ldp:DirectContainer;
-   dcterms:title "The assets of JohnZSmith";
-   ldp:membershipResource &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:hasMemberRelation o:asset;
-   ldp:insertedContentRelation ldp:MemberSubject.
-
-&lt;?firstPage&gt;
-   a ldp:Page;
-   ldp:pageOf &lt;&gt;;
-   ldp:containerSortCriteria (&lt;#SortValueAscending&gt;).
-
-&lt;#SortValueAscending&gt;
-   a ldp:ContainerSortCriterion;
-   ldp:containerSortOrder ldp:Ascending;
-   ldp:containerSortPredicate o:value.
-
-&lt;http://example.org/netWorth/nw1&gt;
-   a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
-
-&lt;a1&gt;
-   a o:Stock;
-   o:value 100.00 .
-&lt;a2&gt;
-   a o:Cash;
-   o:value 50.00 .
-&lt;a3&gt;
-   a o:RealEstateHolding;
-   o:value 300000 .
-</pre>
-		<p>
-			As you can see by the addition of the <code>ldp:ContainerSortCriteria</code> 
-			predicate, the <code>o:value</code> predicate is used
-			to order the page members in ascending order.  It is up to the domain model
-			and server to determine the appropriate predicate to indicate the
-			resource’s order within a page, and up to the client receiving this 
-			representation to use that order in whatever way is appropriate, for 
-			example to sort the data prior to presentation on a user interface. Also
-			as it is possible for a container to have as its members other containers,
-			the ordering approach doesn't change as containers themselves are LDPRs and the
-			properties from the domain model can be leveraged for the sort criteria.
-		</p>
-	</section><!-- Was 5.1.2 / #ldpc-ordering -->
 </section>
 
 <section id="ldpc-general">
@@ -1667,13 +1286,7 @@
 		<a href="#prefer-parameters">which subsets of LDP-defined state</a>
 		the client is interested in processing,
 		to influence the set of triples returned in representations of an LDPC, 
-		particularly for large LDPCs.  
-		Non-normative note: the LDPC might be paged; <a title="Paged resource">paged resources</a> provide 
-		no guarantee that all triples of a given subset, for example 
-		<a title="Containment triples">containment triples</a>, 
-		are grouped together on one page or on a sequence of consecutive 
-		<a title="Single-page resource">pages</a>
-		(see <a href="#ldpr-Paging" class="sectionRef"></a>).
+		particularly for large LDPCs.  See also [[LDP-PAGING]].
 	</h2></section>
 	
 </section>
@@ -1689,77 +1302,6 @@
 		section on <a href="#ldpc-mbrpred">LDPC membership predicates</a>.
 	</h2></section><!-- Was 5.3.1 / #ldpc-5_3_1 -->
 	
-	<section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
-		represent the members of a paged LDPC in a sequential
-		order.  If the server does so, it MUST specify the order using a triple 
-		whose subject is the page URI, 
-		whose predicate is <code>ldp:containerSortCriteria</code>, 
-		and whose object is a <code>rdf:List</code> of
-		<code>ldp:containerSortCriterion</code> resources.  
-		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
-		[[!sparql11-query]].
-		Sorting criteria MUST be the same for all pages of a representation; if
-		the criteria were allowed to vary, the ordering among members of a container
-		across pages would be undefined. 
-		The first list entry provides the primary
-		sorting criterion, any second entry provides a secondary criterion used to order members considered
-		equal according to the primary criterion, and so on.
-		See <a href="#ldpc-ordering" class="sectionRef"></a> for
-		an example.
-	</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
-	
-	<section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
-		in every <code>ldp:containerSortCriterion</code> list entry, 
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortPredicate</code> 
-		and whose object is 
-		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
-		The only literal data types whose behavior LDP constrains are those defined
-		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!sparql11-query]].  Other data types
-		can be used, but LDP
-		assigns no meaning to them and interoperability will be limited.
-	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
-	
-	<section id="ldpc-sortorder"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
-		in every <code>ldp:containerSortCriterion</code> list entry, 
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortOrder</code> 
-		and whose object describes the order used.
-		LDP defines two values,
-		<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
-		as the object of this triple.  Other values can be used, but LDP
-		assigns no meaning to them and interoperability will be limited.
-	 </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
-	
-	<section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
-		in any <code>ldp:containerSortCriterion</code> list entry,
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortCollation</code> 
-		and whose object identifies the collation used.
-		LDP defines no values for use
-		as the object of this triple.  While it is better for interoperability to use
-		open standardized values, any value can be used.
-		When the <code>ldp:containerSortCollation</code> triple is absent and the 
-		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
-		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!sparql11-query]] using two-argument <code>fn:compare</code>, that is, 
-		it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code> 
-		was the specified collation.
-		When the <code>ldp:containerSortCollation</code> triple is present and the 
-		<a title="page-ordering values">page-ordering values</a> are strings or simple literals 
-		[[!sparql11-query]], the
-		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the 
-		specified collation.
-		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
-		involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
-	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
 </section>
 
 <section id="ldpc-HTTP_POST">
@@ -2091,7 +1633,7 @@
 
 <section id="specs-rdf" class="informative">
 <h2>RDF</h2>
-Reference: [[RDF11-CONCEPTS]]
+Reference: [[rdf11-concepts]]
 
 	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR 
 		can have triples with any subject(s).  The URL used to retrieve the
@@ -2114,18 +1656,6 @@
 
 </section> 
 
-<section id="specs-paging" class="informative">
-<h2>Feed paging and archiving</h2>
-Reference: [[RFC5005]]
-
-	<section id="ldp-paging-incomplete"><h2 class="normal">A <a title="LDP client">LDP client</a>  
-		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
-		complete, or make assumptions to that effect.
-		[[RFC5005]].
-	</h2></section>
-
-</section> 
-
 </section> <!-- Base specs -->
 
 <section>
@@ -2566,6 +2096,7 @@
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
 <ul>
+	<li>2014-02-18 - Factored out paging and sorting into separate spec LDP-Paging (SS) </li>
 	<li>2014-02-18 - Reference cleanup and tweak LDP-RS term (SS) </li>
 	<li>2014-02-17 - Reference to RDF Document into terms (SS) </li>
 	<li>2014-02-17 - Adopted container hierarchy and merged Indirect Container into Container (SS) </li>