--- 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>( <> , 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 => 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 -> 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->4.10.2.4.3,4.10.2.6->4.10.2.4.1,4.10.2.7->4.10.2.4.2 and added samples (SS)</li>
<li>2013-07-24 - Changed ldp:ascending->ldp:Ascending, ldp:descending->ldp:Descending, ldp:non-member-resource ->ldp:nonMemberResource (SS)</li>
- <li>2013-07-24 - Added term <a title="Page resource"></a> (SS)</li>
+ <li>2013-07-24 - Added term "Page resource" (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->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>