issue-58 proofing nits
authorJohn Arwe
Wed, 10 Jul 2013 08:51:20 -0400
changeset 178 0ec347702232
parent 177 584588474886
child 180 5c0da415b275
issue-58 proofing nits
ldp.html
--- a/ldp.html	Tue Jul 09 22:30:00 2013 -0500
+++ b/ldp.html	Wed Jul 10 08:51:20 2013 -0400
@@ -239,11 +239,12 @@
 	
 	<dt><dfn>Resource inlining</dfn></dt>
 	<dd>
-		The practice of responding to a HTTP <code>GET</code> request made to a <code>request-URI</code> R0 with
-		a representation that includes the state of R0, the <em>entire</em> state of resources accessed through
-		<em>other</em> <code>request-URI</code>(s) R1...Rn, and assertions from the server identifying the resources whose
+		The practice of responding to a HTTP <code>GET</code> request made to a <code>request-URI</code> R<sub>0</sub> with
+		a representation that includes the state of R<sub>0</sub>, the <em>entire</em> state of resources accessed through
+		<em>other</em> <code>request-URI</code>(s) R<sub>1</sub>...R<sub>n</sub>, <em>and assertions</em> from the server 
+		identifying the additional resources whose
 		entire state has been provided.
-		R1...Rn identify the inlined resource(s).
+		R<sub>1</sub>...R<sub>n</sub> identify the inlined resource(s).
 		See <a href="#ldpr-inlining" class="sectionRef"></a> for details.
 	<p></p></dd>
 	
@@ -856,7 +857,8 @@
 	<ul>
 	<li><p>
 		Provenance is lost: because RDF graphs from multiple HTTP resources are merged in the
-		response without quotation, it is impossible for a client to reliably know which
+		response without attributing each statement to its originating graph (i.e. without quotation),
+		it is impossible for a client to reliably know which
 		triples came from which HTTP resource(s).  A general solution allowing quotation is
 		RDF Datasets; that is expected to be standardized independently, and can be used in these cases
 		once it is available.
@@ -2023,7 +2025,7 @@
 <section class='appendix informative' id="todos">
 <h1>Editor Todos and Notes</h1>
 <p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
-editors use.  They have not meaning in final product of a published working draft and will be removed prior to publishing.</p>
+editors use.  They have no meaning in final product of a published working draft and will be removed prior to publishing.</p>
 <ul>
 	<li>5.1.4 ordering example  - add example with >1 predicate, and collation sorting</li>
 	<li>Insert some additional examples</li>
@@ -2059,6 +2061,45 @@
  allowable write operations.  I suggest adding the statement, "An LDPR server
  MAY require a user to be authenticated and authorized before this action is 
  permitted." to each of those sections.', consider place to edit this in.</li>
+	<li>(IN)Consistency issues
+<ul>
+	<li><a href="#ldpr-inlining" class="sectionRef"></a> + probably other sections say things like "LDP does not provide clients...".  
+	Should those read "LDP 1.0..." instead?
+	</li><a href="#ldpr-inlining" class="sectionRef"></a>
+		we have a mix of way we reference HTTP verbs, in this section (and a few others) we have "<code>GET</code>" vs. "GET".
+	<li><a href="#ldpr-inlining" class="sectionRef"></a>
+		request-URI or Request-URI
+	</li>
+	<li><a href="#ldpr-inlining" class="sectionRef"></a>
+		wonder how consistent we are with formatting headers (we should search/replace to keep them all the same
+	</li>
+	<li><a href="#ldpc-inlining" class="sectionRef"></a>
+		"LDPC Servers" and "LDP Clients" other areas we use lowercase form of servers and clients...we should agree on one and use it
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+	<li>
+	</li>
+</ul>
+	</li>
 </ul>
 	<div class="ldp-issue-open">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>