Folded #ldpclients section into #ldprs
authorsspeiche
Mon, 03 Mar 2014 14:14:48 -0500
changeset 518 f64cf213ec81
parent 517 5971b0e54055
child 519 0a61b68f0a67
Folded #ldpclients section into #ldprs
ldp.html
--- a/ldp.html	Mon Mar 03 11:31:33 2014 -0500
+++ b/ldp.html	Mon Mar 03 14:14:48 2014 -0500
@@ -3,7 +3,6 @@
 	TODO: Search for them within this document.
 	TODO: Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
 	TODO: Add new "discovery of server capabilities" non-norm section
-    TODO: Consider folding LDP Clients section, feels a bit out of place
     TODO: Consider adding Venn diagram for differences of LDPCs
  -->
 <html>
@@ -413,17 +412,19 @@
   <li>1. Introduction: <b>non-normative</b></li>
   <li>2. Terminology: <b>normative</b></li>
   <li>3. Conformance: <b>normative</b></li>
-  <!-- TODO: section numbering is OFF - LDP clients -->
   <li>4. Linked Data Platform Resources: <b>normative</b></li>
   <li>5. Linked Data Platform Containers: <b>normative</b></li>
-  <li>6. HTTP Header Definitions: <b>normative</b></li>
+  <li>6. Notable information from normative references: <b>non-normative</b></li>
+  <li>7. HTTP Header Definitions: <b>normative</b></li>
+  <li>8. Security Considerations: <b>non-normative</b></li>
   <li>A. Acknowledgements: <b>non-normative</b></li> 
   <li>B.1 Normative references: <b>normative</b></li>
   <li>B.2 Non-normative references: <b>non-normative</b></li>
 </ul>
 
 <p>A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
-<a href="#ldpclient" class="sectionRef"></a>.
+<a href="#ldpr" class="sectionRef"></a> and also
+<a href="#ldpc" class="sectionRef"></a>.
 </p>
 
 <p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in 
@@ -433,64 +434,6 @@
 </p>
 </section>
 
-<section id="ldpclient">
-<h1>Linked Data Platform Clients</h1>
-<p>All of the following are conformance rules for <a title="LDP client">LDP Clients</a>.
-</p>
-<section><h2>General</h2>
-
-	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
-		<a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple values for <code>rdf:type</code>.
-	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
-	
-	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
-		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
-		of a given LDP-RS can change over time.
-	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
-	
-	<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
-		LDP-RS of a particular type at an arbitrary server is open, in the
-		sense that different resources of the same type may not all have the
-		same set of predicates in their triples, and the set of predicates that
-		are used in the state of any one LDP-RS is not limited to any pre-defined
-		set.
-	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
-	
-	<section id="ldpr-cli-preservetriples"><h2 class="normal">
-		A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RS using HTTP <code>GET</code> that
-		it doesn’t change whether it understands the predicates or not, when
-		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
-		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
-		[[RFC5789]].
-	</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
-	
-	<section id="ldpr-cli-can-hint"><h2 class="normal">
-		<a title="LDP client">LDP clients</a> MAY 
-		provide LDP-defined hints that allow servers to optimize the content of responses.
-		<a href="#prefer-parameters" class="sectionRef"></a> defines hints that apply to 
-		<a title="Linked Data Platform RDF Source">LDP-RSs</a>.
-	</h2></section> 
-	
-	<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
-		<a title="LDP client">LDP clients</a> MUST 
-		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 paging, returning a page of representation instead of full resource
-		representation [[!LDP-PAGING]].
-	</div></h2>
-	</section> 
-
-	
-</section>
-</section> <!-- Client constraints -->
-
 <section id="ldpr">
 <h1>Linked Data Platform Resources</h1>
 
@@ -799,7 +742,24 @@
 		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
 		possible.
 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+
+	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple values for <code>rdf:type</code>.
+	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
 	
+	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
+		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
+		of a given LDP-RS can change over time.
+	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
+	
+	<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
+		LDP-RS of a particular type at an arbitrary server is open, in the
+		sense that different resources of the same type may not all have the
+		same set of predicates in their triples, and the set of predicates that
+		are used in the state of any one LDP-RS is not limited to any pre-defined
+		set.
+	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
+		
 	<section id="ldprs-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
@@ -807,6 +767,37 @@
 		must be explicitly represented, unless noted otherwise within this document.
 	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
 	
+	<section id="ldpr-cli-preservetriples"><h2 class="normal">
+		A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RS using HTTP <code>GET</code> that
+		it doesn’t change whether it understands the predicates or not, when
+		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
+		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
+		[[RFC5789]].
+	</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
+	
+	<section id="ldpr-cli-can-hint"><h2 class="normal">
+		<a title="LDP client">LDP clients</a> MAY 
+		provide LDP-defined hints that allow servers to optimize the content of responses.
+		<a href="#prefer-parameters" class="sectionRef"></a> defines hints that apply to 
+		<a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+	</h2></section> 
+	
+	<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
+		<a title="LDP client">LDP clients</a> MUST 
+		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 paging, returning a page of representation instead of full resource
+		representation [[!LDP-PAGING]].
+	</div></h2>
+	</section> 
+	
 </section> <!-- ldprs-general -->
 
 <section id="ldprs-HTTP_GET">
@@ -2219,6 +2210,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-03-03 - Folded #ldpclients section into #ldprs (SS) </li>
 	<li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
 	<li>2014-02-28 - Combined rules for container triples (SS) </li>
 	<li>2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)</li>
@@ -2261,7 +2253,7 @@
 	<li>2014-01-30 - ACTION-123 Added concepts of LDP-RDF-Resource and LDP-Binary-Resource (SS)</li>
 	<li>2014-01-29 - Fix up conformance section to use new LDP client section (SS)</li>
 	<li>2014-01-21 - Updated reference to LDP BP&amp;G editor's draft and added ref to LDP-UCR (SS)</li>
-	<li>2014-01-21 - Removed redudant reqs that have been moved to <a href="#ldpclient"></a> (SS)</li>
+	<li>2014-01-21 - Removed redudant reqs that have been moved to #ldpclient (SS)</li>
 	<li>2014-01-21 - Fixed formating with &gt;h2 formatting (SS)</li>
 	<li>2014-01-21 - Put reference to <a href="#base-specs">base-specs</a> into intro section (SS)</li>
 	<li>2014-01-17 - First attempt at correcting section ordering and anchors (SS)</li>