--- 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>