Action-122 close ISSUE-91, by adding that for an LDPC the link header is type=LDPC
--- a/ldp.html Thu Jan 02 10:47:51 2014 -0500
+++ b/ldp.html Thu Jan 02 13:59:20 2014 -0500
@@ -542,19 +542,33 @@
</div>
-->
<div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
+ exposing LDPRs
MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
in all responses to requests made
- to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
- presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
- The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
- that clients can inspect dynamically at run-time. Conservative clients should note that
- <a href="#ldpr-4_2_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
+ to the LDPR's HTTP <code>Request-URI</code>.
+ </div>
+ <blockquote>
+ <p>
+ Note:
+ The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification
+ on a specific resource in a way that clients can inspect dynamically at run-time.
+ This is <strong>not</strong> equivalent to the
+ presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an RDF resource.
+ The presence of this header asserts that the server complies with the LDP specification's constraints on
+ HTTP interactions with LDPRs, that is
+ it asserts that the resource <a href="#ldpr-4_2_8">has Etags</a>, <a href="#ldpr-4_2_2">has an RDF representation</a>, and so on,
+ which is not true of all Web resources served as RDF media types.
+ </p>
+ <p>
+ Note:
+ <a href="#ldpr-4_2_3">A LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
that LDP support advertised on one HTTP <code>Request-URI</code> means that other
resources on the same server are also LDPRs. Each HTTP <code>Request-URI</code> needs to be
- individually inspected by a conservative client, in the absence of outside information.
- </div>
+ individually inspected, in the absence of outside information.
+ </p>
+ </blockquote>
<div id="ldpr-4_2_11" class="rule">4.2.11 <a title="LDP server">LDP servers</a>
MUST NOT require LDP clients to implement inferencing in order to recognize the subset
of content defined by LDP. Other specifications built on top of LDP may require clients
@@ -1254,6 +1268,7 @@
Content-Type: text/turtle; charset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
+Link: <http://www.w3.org/ns/ldp/Container>; rel="type"
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -1537,6 +1552,16 @@
ldp:containerResource </people/roger>;
ldp:insertedContentRelation foaf:primaryTopic .
-->
+ <div id="ldpc-5_2_11" class="rule">5.2.11 <a title="LDP server">LDP servers</a>
+ exposing LDPCs
+ MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
+ with a target URI of <code>http://www.w3.org/ns/ldp/Container</code>, and
+ a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
+ in all responses to requests made
+ to the LDPC's HTTP <code>Request-URI</code>.
+ The <a href="#4_2_10">notes on the corresponding LDPR constraint</a> apply
+ equally to LDPCs.
+ </div>
</section>
@@ -1646,10 +1671,17 @@
creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for
details on how clients can discover whether a LDPC supports this behavior.
</div>
- <div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <a title="LDP server">LDP servers</a> MUST create an LDPR from a
- RDF representation in the request entity body. The newly created LDPR could also be a LDPC, therefore servers MAY
- allow the creation of LDPCs within a LDPC.
+ <div id="ldpc-5_4_4" class="rule">5.4.4 <a title="LDP server">LDP servers</a> that successfully create a new resource from a
+ RDF representation in the request entity body MUST honor the client's requested interaction model(s).
+ If any model cannot be honored, the server MUST fail the request.
</div>
+ <ul>
+ <li>If the request header <a href="#ldpr-4_2_10">specifies an LDPR interaction model</a>, then the server MUST create an LDPR.</li>
+ <li>If the request header <a href="#ldpc-5_2_11">specifies an LDPC interaction model</a>, then the server MUST create an LDPC.
+ </li>
+ <li>This specification does not constrain the server's behavior in other cases.</li>
+ <p>Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
+ </ul>
<div id="ldpc-5_4_5" class="rule">5.4.5 <a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
@@ -1841,7 +1873,7 @@
<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]].
This is the mechanism by which clients discover the URL of the non-member resource.
If no such <code>Link</code>
- header is present, then conservative clients will assume that the LDPC does not have a corresponding
+ header is present, then clients will assume that the LDPC does not have a corresponding
non-member resource.
For example, if there is a LDPC with URL <code><containerURL></code> whose corresponding
non-member resource
@@ -2200,6 +2232,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
<li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
<li>2013-11-27 - ACTION-101 Added informative <a href="#security">security</a> section (SS)</li>
<li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>