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