ldp.html
changeset 416 166375df8bf8
parent 415 12864dde579d
child 417 a7cdde712c1f
--- a/ldp.html	Tue Nov 12 17:18:32 2013 -0500
+++ b/ldp.html	Mon Nov 18 08:32:01 2013 -0500
@@ -359,7 +359,7 @@
 	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
 	coherency/completeness considerations apply.
 	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
-	</p><p>
+	<p>
 	Note: the choice of terms was designed to help authors and readers clearly differentiate between
 	the <a title="Paged resource"><em>resource being paged</em></a>, and the 
 	<a title="Single-page resource"><em>individual page resources</em></a>, 
@@ -692,6 +692,8 @@
 		same set of predicates in their triples, and the set of predicates that
 		are used in the state of any one resource is not limited to any pre-defined
 		set.
+		<!-- TODO: This seems to fly in the face of systems that are closed, which we have many, which have a way to discover via some 
+		out of bands means. -->
 	</div>
 	<div id="ldpr-4_5_4" class="rule">4.5.4 
 		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
@@ -702,6 +704,7 @@
 		information about which triples could not be
 		persisted.
 		The format of the 4xx response body is not constrained by LDP.
+		<!-- TODO: MUST respond with Link rel='describedBy' as in 4.2.13 -->
 	</div>
 	<div id="ldpr-4_5_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
 		it doesn’t change whether it understands the predicates or not, when
@@ -713,7 +716,7 @@
 	</div>
 	<div id="ldpr-4_5_7" class="rule">4.5.7 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
 		requiring detailed knowledge of server-specific constraints.  
-		This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
 	</div>		
 </section>
 		
@@ -1488,11 +1491,12 @@
 		the predicate <var>P</var> is present in the client's input.
 		For example, if the client POSTs RDF content to a container
 		that causes the container to create a new LDPR, and that content contains the triple 
-		<var>( <> , foaf:primaryTopic , mypet#Zaza )</var>
+		<var>( &lt;&gt; , foaf:primaryTopic , mypet#Zaza )</var>
 		<code>foaf:primaryTopic</code> says
 		that the <var>member-derived-URI</var> is <var>mypet#Zaza</var>.  
 		</li>
 		</ul>
+	</div>
 	<!-- Action-112 rewrote this 2013-11-12, original in this comment
 	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPCs have members whose URIs are not directly
 	    URIs minted upon LDPC member creation, for example URIs with a non-empty fragment identifier [[RFC3986]]. 
@@ -1547,7 +1551,7 @@
 <h2>HTTP GET</h2>
 
 	<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of 
-		<a href="Membership triples">membership triples</a> following one of the consistent 
+		<a title="Membership triples">membership triples</a> following one of the consistent 
 		patterns from that definition.
 		The membership-constant-URI of the triples MAY be the container itself
 		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
@@ -1555,7 +1559,7 @@
 	</div>
 	<div id="ldpc-5_3_2" class="rule">5.3.2 <a title="LDP server">LDP servers</a> MAY 
 		represent the members of a paged LDPC in a sequential
-		order.  If the server does so, it MUST be specify the order using a triple 
+		order.  If the server does so, it MUST specify the order using a triple 
 		whose subject is the page URI, 
 		whose predicate is <code>ldp:containerSortCriteria</code>, 
 		and whose object is a <code>rdf:List</code> of
@@ -1569,7 +1573,7 @@
 		sorting criterion, any second entry provides a secondary criterion used to order members considered
 		equal according to the primary criterion, and so on.
 		<!-- Convert cases like this to a sectionRef -->
-		See section <a href="#ldpc-ordering">5.1.3 Ordering</a> for
+		See section <a href="#ldpc-ordering">5.1.2 Ordering</a> for
 		an example.
 	</div>
 	<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations 
@@ -1580,7 +1584,7 @@
 		whose predicate is <code>ldp:containerSortPredicate</code> 
 		and whose object is 
 		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
-		The only predicate data types whose behavior LDP constrains are those defined
+		The only literal data types whose behavior LDP constrains are those defined
 		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
 		can be used, but LDP
 		assigns no meaning to them and interoperability will be limited.
@@ -1677,8 +1681,9 @@
 	</div>
 	<div id="ldpc-5_4_9" class="rule">5.4.9 <a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
-		This is a consequence of the requirement to 
-		<a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
+		<!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints.  
+		           Also, should this call out LDPRs explicity?  Would think we could just have "resources" statement. -->
 	</div>
 	<div id="ldpc-5_4_10" class="rule">5.4.10 <a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
 		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
@@ -1687,8 +1692,7 @@
 	</div>
 	
 	<div id="ldpc-5_4_11" class="rule">5.4.11 <a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
-		SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
-		general requirements on LDPCs</a>.
+		SHOULD NOT re-use URIs.
 	</div>
 	
 	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
@@ -1750,8 +1754,7 @@
 	</div>
 	
 	<div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
-		SHOULD NOT re-use URIs, per the <a href="#ldpc-5_2_9">
-		general requirements on LDPCs</a>.
+		SHOULD NOT re-use URIs.
 	</div>
 	
 </section>
@@ -1844,7 +1847,23 @@
 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
 	header whose target URI is the associated LDPR, and whose link relation type is 
-	<code>meta</code> [[!RFC5988]].</div>
+	<code>meta</code> [[!RFC5988]].
+	
+	<!-- TODO: Consider some improvement to this:
+	
+	Does a LDPC create a non-LDPR? or does and LDPC server do this?
+	What is "it" in the first sentence?
+	Adding a Request-URI clause to the last sentence may help clarify a couple things.
+	
+	5.9.2 When an <a>LDP server</a> creates a non-LDPR (e.g. binary) member (for example, one whose 
+	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) <strike>it</strike> the LDPC might create an associated LDPR to contain data about the 
+	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs (identified by their Request-URI) that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
+	header whose target URI is the associated LDPR, and whose link relation type is 
+	<code>meta</code> [[!RFC5988]].
+	
+	 -->
+	
+	</div>
 </section> <!-- h2 -->
 
 </section> <!-- h1 -->
@@ -2026,7 +2045,7 @@
 
 <div class="ldp-issue-open">
 <p>
-Given that it's from base specs => important to understand, should be moved up before 
+Given that it's from base specs =&gt; important to understand, should be moved up before 
 most of the normative sections IMO - renumbering hit again.
 </p>
 </div>
@@ -2162,6 +2181,7 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <ul>
+	<li>2013-11-18 - Various editorial and validation fixes (SS)</li>
     <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
     <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
     <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
@@ -2174,7 +2194,7 @@
     <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
     <li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>
     <li>2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)</li>
-    <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -> SHOULD (JA)</li>
+    <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -&gt; SHOULD (JA)</li>
     <li>2013-10-21 - Mock up status code 209 Related Content (JA)</li>
     <li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
     <li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
@@ -2192,7 +2212,7 @@
 	<li>2013-07-24 - Moved 4.7.2 (from HEAD) to 4.3.2 (GET), shifted rest of GET section by one (SS)</li>
 	<li>2013-07-24 - Moved 4.10.2.5-&gt;4.10.2.4.3,4.10.2.6-&gt;4.10.2.4.1,4.10.2.7-&gt;4.10.2.4.2 and added samples (SS)</li>
 	<li>2013-07-24 - Changed ldp:ascending-&gt;ldp:Ascending, ldp:descending-&gt;ldp:Descending, ldp:non-member-resource -&gt;ldp:nonMemberResource (SS)</li>
-	<li>2013-07-24 - Added term <a title="Page resource"></a> (SS)</li>
+	<li>2013-07-24 - Added term &quot;Page resource&quot; (SS)</li>
 	<li>2013-07-24 - Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI (SS)</li>
     <li>2013-07-23 - Added informative <a href="#ldpr-informative" class="sectionRef"></a>, therefore shifting all sections by one 4.1-&gt;4.2, etc (SS)</li>
 	<li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>