Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos
Mon, 10 Feb 2014 15:38:29 -0500
changeset 481 beb136ede044
parent 480 96f2d9c4a742
child 482 57c86943ab63
Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos
--- a/ldp.html	Mon Feb 10 15:22:40 2014 -0500
+++ b/ldp.html	Mon Feb 10 15:38:29 2014 -0500
@@ -3,7 +3,7 @@
 	TODO: Search for them within this document.
 	TODO: Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
-	TODO: Stabilize membership* names
+	TODO: Stabilize terminology/names such as (LDP-RR, LDP-BR, LDP-BC, LDP-DC, LDP-IC) and membership* predicate names
 	TODO: Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
      and see if there is a friendlier way to phrase it.
 	TODO: Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
@@ -19,9 +19,6 @@
 	  Links to examples might be an 80-20 solution. 
 	- TODO: 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9. 
 	  Currently does not work when printing.
- Misc during LC comments:
-    - TODO: #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is.  Also example is missing ldp:nextPage.
@@ -643,10 +640,6 @@
 		in all responses to requests made 
 		to the LDPR's HTTP <code>Request-URI</code>. 
 	</h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
-	<!-- TODO: Is this RDFResource or just Resource?  Language gets odd in section #ldpc-post-createrdf , where it says "then the server MUST create
-	an LDPR".  If client sent a JPEG and type=#RDFResource, what should the server do?  If the more generic #Resource, seems to catch
-	what is intended -->
@@ -867,8 +860,7 @@
 	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs 
 		beyond those in [[!HTTP11]].  Other sections of this specification, for example 
 		<a href="#ldpr-HTTP_PATCH">PATCH</a>,
-		<a href="#header-accept-post">Accept-Post</a>
-		and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
+		<a href="#header-accept-post">Accept-Post</a>,
 		add other requirements on <code>OPTIONS</code> responses.
@@ -1112,23 +1104,6 @@
-<section id="ldpr-paging-HTTP_OPTIONS">
-<h3>HTTP OPTIONS</h3>
-	<p>In addition to the requirements set forth in 
-		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a> on HTTP <code>OPTIONS</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>.
-		Note that LDP only requires enough from <code>OPTIONS</code> 
-		for discovery of paging support on a resource, which is considerably
-		less than is required for HTTP <code>GET</code>.  
-		This lowers server implementation effor	t.
-	</p>
-	<!-- TODO: This section is empty - looks weird, and it is linked to from other sections -->
-</section> <!-- h3 -->
 </section> <!-- h2 -->
 </section> <!-- h1 -->
@@ -2600,6 +2575,7 @@
 <!-- <blockquote><em><a href="">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <!-- <blockquote><em><a href="">Last Call Draft</a></em></blockquote> -->
+	<li>2014-02-10 - Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos (SS)</li>
 	<li>2014-02-10 - Updated LDPC DELETE language and cleanup todos (SS)</li>
 	<li>2014-02-10 - Resolved a few editoral TODO's (JA)</li>
 	<li>2014-02-08 - Put final stake in heart of 'informative' (waves to Sandro), update boilerplate for readability per Arnaud (JA)</li>