Various minor editorial fixups
authorsspeiche
Wed, 24 Jul 2013 09:26:01 -0400
changeset 229 8ddd81e6113c
parent 228 ec118c66c122
child 230 b0111e4397ab
Various minor editorial fixups
ldp.html
--- a/ldp.html	Wed Jul 24 08:54:11 2013 -0400
+++ b/ldp.html	Wed Jul 24 09:26:01 2013 -0400
@@ -15,6 +15,11 @@
     - 	The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
 	referring readers to SPARQL 1.1.  Which normative reference do we want?
  Various pre-LC comments:
+    - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate, 
+	  5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse, 
+	  5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation, 
+	  (JohnA) I found these particularly hard to read.  And I perpetrated the SortCollation paragraphs.  
+	  Links to examples might be an 80-20 solution. 
     - John A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0054.html
                         http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0056.html
     - P-A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0071.html
@@ -563,7 +568,8 @@
 <h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
 		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
-		Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
+		Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a> 
+		and <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.</p>
 	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
 </section>
 
@@ -743,7 +749,7 @@
 		Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
 	</div>
 	<div id="ldpr-pagingGET-4" class="rule">4.10.2.4 LDPR servers that support paging MUST include in the page
-		representation a representation for the LDPR.
+		representation a representation for the page resource.
 	</div>
 	<div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation MUST have one triple with the subject
 		of the page, predicate of <code>ldp:nextPage</code> and
@@ -1488,7 +1494,7 @@
 	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
 	and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
 	</div>	
-	<div id="ldpc-5_4_13" class="rule">5.4.13 LDPR servers that support <code>POST</code> MUST
+	<div id="ldpc-5_4_13" class="rule">5.4.13 LDPC servers that support <code>POST</code> MUST
 		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
 		responses, listing post document media type(s) supported by the server.
 		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
@@ -1549,7 +1555,7 @@
 
 <section>
 <h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
-	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
+	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
 		only when a LDPC supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
@@ -1579,7 +1585,7 @@
 <section>
 <h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
-		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPR servers must also include HTTP headers
+		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPC servers must also include HTTP headers
 		on response to <code>OPTIONS</code>, see <a href="#ldpr-4_7_2">4.7.2</a>.
 		Thus, implementers supporting <code>HEAD</code> should also carefully read the
 		<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>