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.
- http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
-->
<html>
<head>
@@ -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 -->
<blockquote>
<p>
Note:
@@ -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.
</p>
@@ -1112,23 +1104,6 @@
</h2></section>
</section>
-<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="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-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>