--- a/ldp.html Mon Sep 30 16:53:10 2013 -0400
+++ b/ldp.html Tue Oct 01 11:11:32 2013 -0400
@@ -310,13 +310,81 @@
<li>B.2 Informative references: <b>informative</b></li>
</ul>
-<p>A conforming <b>LDP server</b> is an application program that processes HTTP
-requests and generates HTTP responses that conform to the rules defined in <a href="#ldpr" class="sectionRef"></a>
-and <a href="#ldpc" class="sectionRef"></a>.</p>
+<div class="ldp-issue-closed">
+<p>(OLD) A conforming <b>LDP server</b> is an application program that processes HTTP requests
+and generates HTTP responses that conform to the rules defined in
+<a href="#ldpr" class="sectionRef"></a> and <a href="#ldpc" class="sectionRef"></a>.
+</p>
-<p>A conforming <b>LDP client</b> is an application program that generates HTTP
-requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
-and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>
+<p>(OLD) A conforming <b>LDP client</b> is an application program that generates HTTP
+requests and processes HTTP responses that conform to the rules defined in <a href="#ldpr" class="sectionRef"></a>
+and <a href="#ldpc" class="sectionRef"></a>.
+</p>
+</div>
+
+<div class="ldp-issue-open">
+<p>(NEW) A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
+<a href="#ldpclient" class="sectionRef"></a>.
+</p>
+
+<p>(NEW) A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in
+<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
+<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
+LDP does not constrain its behavior when serving other HTTP resources.
+</p>
+
+<p>(NEW) LDP defines several classes of LDP servers, and places different conformance requirements on each of them.
+NOTE: "Basic" and "advanced" used here for drafting purposes; they correspond to 'vanilla' and 'chocolate', respectively.
+Final names TBD.
+</p>
+<ul>
+ <li><p>A conforming <b><dfn>basic LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
+ for basic LDP servers, as shown below. Its content model is generally open and the server typically stores triples on behalf of clients
+ with minimal (if any) restrictions.
+ </p></li>
+ <li><p>A conforming <b><dfn>advanced LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
+ for advanced LDP servers, as shown below. Its content model can be open or closed, and the server may impose non-trivial
+ restrictions on triples stored on behalf of conforming HTTP clients.
+ </p></li>
+</ul>
+
+<section>
+<h5>Example conformance rules</h5>
+
+<p>The following informative examples show how LDP assigns conformance criteria to each class of LDP servers using a single rule.</p>
+
+<section>
+<h6>Example: the same criteria apply to both basic and advanced LDP servers</h6>
+<div class="example">
+ <div class="rule">LDP servers SHOULD ... </div>
+</div>
+
+<p>The preceding rule is equivalent to the following pair of rules:</p>
+<div class="example">
+ <div class="rule">Basic LDP servers SHOULD ... </div>
+ <div class="rule">Advanced LDP servers SHOULD ... </div>
+</div>
+</section>
+
+<section>
+<h6>Example: different criteria apply to basic and advanced LDP servers</h6>
+<p>Trying out different ways of covering each class while minimizing text duplication here. Final format TBD.</p>
+<div class="example">
+ <div class="rule">(proposal 1) LDP servers MUST (basic)/SHOULD (advanced) ... </div>
+ <div class="rule">(proposal 2) Basic LDP servers MUST, and advanced LDP servers SHOULD, ... </div>
+ <div class="rule">(proposal 3) Basic LDP servers MUST ... . Advanced LDP servers SHOULD do so. </div>
+</div>
+
+<p>Each of the preceding rules is equivalent to the following pair of rules:</p>
+<div class="example">
+ <div class="rule">4.8.2 Basic LDP servers MUST ...
+ </div>
+ <div class="rule">4.8.2 Advanced LDP servers SHOULD ...
+ </div>
+</div>
+</section>
+
+</div>
</section>
@@ -329,7 +397,7 @@
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
that conform to the simple patterns and conventions in this section.
HTTP requests to access, modify, create or delete LDPRs are accepted
- and processed by LDPR servers. Most LDPRs are domain-specific resources
+ and processed by <a title="LDP server">LDP servers</a>. Most LDPRs are domain-specific resources
that contain data for an entity in some domain, which could be
commercial, governmental, scientific, religious, or other.</p>
<p>Some of the rules defined in this document provide
@@ -366,12 +434,12 @@
<section id="ldpr-general">
<h2>General</h2>
- <div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
- <div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an RDF representation for LDPRs.
+ <div id="ldpr-4_2_1" class="rule">4.2.1 <a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
+ <div id="ldpr-4_2_2" class="rule">4.2.2 <a title="LDP server">LDP servers</a> MUST provide an RDF representation for LDPRs.
The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
</div>
- <div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
- is common for LDPR servers to need to host binary or text resources
+ <div id="ldpr-4_2_3" class="rule">4.2.3 <a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
+ is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
that do not have useful RDF representations.
</div>
@@ -387,7 +455,7 @@
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
</div>
- <div id="ldpr-4_2_6" class="rule">4.2.6 LDPR servers MAY support standard representations beyond those
+ <div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
necessary to conform to this specification. These
could be other RDF formats, like N3 or NTriples, but non-RDF formats
like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
@@ -397,13 +465,13 @@
UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
normative requirements.
</div>
- <div id="ldpr-4_2_8" class="rule">4.2.8 LDPR server responses MUST use entity tags (either weak or strong
+ <div id="ldpr-4_2_8" class="rule">4.2.8 <a title="LDP server">LDP server</a> responses MUST use entity tags (either weak or strong
ones) as response <code>ETag</code> header values.
</div>
<div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
servers SHOULD enable simple creation and modification of LDPRs.
It is
- common for LDPR servers to put restrictions on representations – for
+ common for <a title="LDP server">LDP servers</a> to put restrictions on representations – for
example, the range of <code>rdf:type</code> predicates, datatypes of
the objects of predicates, and the number of occurrences of predicates in an LDPR, but
servers SHOULD minimize those restrictions. Enforcement of
@@ -411,7 +479,7 @@
that can modify resources. For some server applications, excessive
constraints on modification of resources may be required.
</div>
- <div id="ldpr-4_2_10" class="rule">4.2.10 LDPR servers
+ <div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
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>)
@@ -425,13 +493,13 @@
resources on the same server are also LDPRs. Each HTTP <code>Request-URI</code> needs to be
individually introspected by a conservative client, in the absence of outside information.
</div>
- <div id="ldpr-4_2_11" class="rule">4.2.11 LDPR servers
+ <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
to implement inferencing [[!RDF-CONCEPTS]]. The practical implication is that all content defined by LDP
must be explicitly represented.
</div>
- <div id="ldpr-4_2_12" class="rule">4.2.12 LDPR servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
+ <div id="ldpr-4_2_12" class="rule">4.2.12 <a title="LDP server">LDP servers</a> MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results
in the creation of a new resource.
</div>
@@ -440,24 +508,24 @@
<section id="ldpr-HTTP_GET">
<h2>HTTP GET</h2>
- <div id="ldpr-4_3_1" class="rule">4.3.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
+ <div id="ldpr-4_3_1" class="rule">4.3.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
</div>
- <div id="ldpr-4_3_2" class="rule">4.3.2 LDPR servers MUST support the HTTP response headers defined in
+ <div id="ldpr-4_3_2" class="rule">4.3.2 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in
<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
</div>
- <div id="ldpr-4_3_3" class="rule">4.3.3 LDPR servers SHOULD provide a <code>text/turtle</code>
+ <div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> SHOULD provide a <code>text/turtle</code>
representation of the requested LDPR [[!TURTLE]].
</div>
- <div id="ldpr-4_3_4" class="rule">4.3.4 LDPR servers MAY provide
+ <div id="ldpr-4_3_4" class="rule">4.3.4 <a title="LDP server">LDP servers</a> MAY provide
representations of the requested LDPR beyond those
necessary to conform to this specification, using standard HTTP content negotiation ([[!HTTP11]] Section 12 - Content Negotiation).
If the client does not indicate a preference, <code>text/turtle</code> SHOULD be returned.
</div>
- <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, LDPR
- clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+ <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
</div>
- <div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, LDPR
- clients MUST assume that the <code>rdf:type</code> values
+ <div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
of a given LDPR can change over time.
</div>
</section>
@@ -478,48 +546,48 @@
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
+ <div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, <a title="LDP server">LDP servers</a> MUST
replace the entire persistent state of the identified resource with
the entity representation in the body of the request.
- LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code>
+ <a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code>
and <code>dcterms:creator</code> if they are not under
- client control. Any LDPR servers that wish
+ client control. Any <a title="LDP server">LDP servers</a> that wish
to support a more sophisticated merge of data provided by the client
with existing state stored on the server for a resource MUST use HTTP
<code>PATCH</code>, not HTTP <code>PUT</code>.
</div>
- <div id="ldpr-4_5_2" class="rule">4.5.2 LDPR clients SHOULD use the HTTP <code>If-Match</code>
+ <div id="ldpr-4_5_2" class="rule">4.5.2 <a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
- its representation. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
- to detect collisions. LDPR servers MUST respond with status code 412
+ its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+ to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
(Condition Failed) if <code>ETag</code>s fail to match when there are no other
- errors with the request [[!HTTP11]]. LDPR servers that require conditional requests MUST respond with status code 428
+ errors with the request [[!HTTP11]]. <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
</div>
- <div id="ldpr-4_5_3" class="rule">4.5.3 LDPR clients SHOULD always assume that the set of predicates for a
+ <div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
resource of a particular type at an arbitrary server is open, in the
sense that different resources of the same type may not all have the
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.
</div>
- <div id="ldpr-4_5_4" class="rule">4.5.4 LDPR clients SHOULD assume that an LDPR server could discard triples
+ <div id="ldpr-4_5_4" class="rule">4.5.4 <a title="LDP client">LDP clients</a> SHOULD assume that an <a title="LDP server">LDP server</a> could discard triples
whose predicates the server does not recognize or otherwise chooses
- not to persist. In other words, LDPR servers MAY restrict themselves
- to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates
+ not to persist. In other words, <a title="LDP server">LDP servers</a> MAY restrict themselves
+ to a known set of predicates, but <a title="LDP client">LDP clients</a> MUST NOT restrict themselves to a known set of predicates
when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
</div>
- <div id="ldpr-4_5_5" class="rule">4.5.5 An LDPR client MUST preserve all triples retrieved using HTTP <code>GET</code> that
+ <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
its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
[[RFC5789]].
</div>
- <div id="ldpr-4_5_6" class="rule">4.5.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ <div id="ldpr-4_5_6" class="rule">4.5.6 <a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
</div>
- <div id="ldpr-4_5_7" class="rule">4.5.7 LDPR servers SHOULD allow clients to update resources without
+ <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.
</div>
@@ -533,16 +601,16 @@
<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
<a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.</p>
- <div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
+ <div id="ldpr-4_6_1" class="rule">4.6.1 <a title="LDP server">LDP servers</a> MUST remove the resource identified by the <code>Request-URI</code>.
After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
</div>
- <div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MAY alter the state of other resources as a result of an
+ <div id="ldpr-4_6_2" class="rule">4.6.2 <a title="LDP server">LDP servers</a> MAY alter the state of other resources as a result of an
HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
remove triples from other resources whose subject or object is the
- deleted resource. It is also acceptable and common for LDPR servers to
+ deleted resource. It is also acceptable and common for <a title="LDP server">LDP servers</a> to
not do this – behavior is server application specific.
</div>
</section>
@@ -553,7 +621,7 @@
<code>HEAD</code> responses include the same headers as <code>GET</code> responses.
Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a>
and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
- <div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
+ <div id="ldpr-4_7_1" class="rule">4.7.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.</div>
</section>
<section id="ldpr-HTTP_PATCH">
@@ -561,18 +629,18 @@
<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
+ <div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
especially partial replacement, of their resources [[!RFC5789]]. No
minimal set of patch document formats is mandated by this document.
</div>
- <div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers SHOULD allow clients to update resources without
+ <div id="ldpr-4_8_2" class="rule">4.8.2 <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.
</div>
- <div id="ldpr-4_8_3" class="rule">4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
+ <div id="ldpr-4_8_3" class="rule">4.8.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
</div>
- <div id="ldpr-4_8_4" class="rule">4.8.4 LDPR servers that support <code>PATCH</code> MUST
+ <div id="ldpr-4_8_4" class="rule">4.8.4 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
requests, listing patch document media type(s) supported by the server.
</div>
@@ -589,8 +657,8 @@
add other requirements on <code>OPTIONS</code> responses.
</p>
- <div id="ldpr-4_9_1" class="rule">4.9.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>
- <div id="ldpr-4_9_2" class="rule">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by
+ <div id="ldpr-4_9_1" class="rule">4.9.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.</div>
+ <div id="ldpr-4_9_2" class="rule">4.9.2 <a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
Method tokens in the HTTP response header <code>Allow</code>.
</div>
@@ -622,7 +690,7 @@
are typically a subset of the triples in the resource
- same subject, predicate and object.
</p>
- <p>LDPR servers may respond to requests for a
+ <p><a title="LDP server">LDP servers</a> may respond to requests for a
resource by redirecting the client to the first page resource –
using a 303 “See Other” redirect to the actual URL for the page
resource. Alternatively, clients may introspect the resource for a paged representation
@@ -713,11 +781,11 @@
<section id="ldpr-PagingGET">
<h3>HTTP GET</h3>
-<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, LDPR servers that support paging must also follow the requirements in this section</p>
+<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, <a title="LDP server">LDP servers</a> that support paging must also follow the requirements in this section</p>
- <div id="ldpr-pagingGET-1" class="rule">4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
+ <div id="ldpr-pagingGET-1" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>,
- LDPR servers that support paging SHOULD provide an HTTP <code>Link</code>
+ <a title="LDP server">LDP servers</a> that support paging SHOULD provide an HTTP <code>Link</code>
header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]].
This is the mechanism by which clients discover the URL of the first page. If no such <code>Link</code>
header is present, then conservative clients will assume that the LDPR does not support paging.
@@ -727,15 +795,15 @@
The representation for any page, including the first, will include
the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
</div>
- <div id="ldpr-pagingGET-2" class="rule">4.10.2.2 LDPR servers MAY split the response representation of any LDPR.
+ <div id="ldpr-pagingGET-2" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MAY split the response representation of any LDPR.
See <a href="#ldpr-Paging" class="sectionRef"></a> for
additional details.
</div>
- <div id="ldpr-pagingGET-3" class="rule">4.10.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
+ <div id="ldpr-pagingGET-3" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a> that initiate paging SHOULD respond to requests for a LDPR
by redirecting the client to the first page resource using a <code>303 See
Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
</div>
- <div id="ldpr-pagingGET-4" class="rule">4.10.2.4 LDPR servers that support paging MUST include a representation for the page resource.
+ <div id="ldpr-pagingGET-4" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> that support paging MUST include a representation for the page resource.
</div>
<div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation MUST have one triple with the subject
of the page, predicate of <code>ldp:nextPage</code> and
@@ -762,7 +830,7 @@
<section id="ldpr-paging-HTTP_OPTIONS">
<h3>HTTP OPTIONS</h3>
-<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers MUST indicate their support for paging by
+<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for paging by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
</div>
@@ -1049,7 +1117,7 @@
constructs like Seq and List for expressing order.
</p>
<p>
- Order becomes more important for LDPC servers when containers are
+ Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
paginated. If the server does not respect ordering when constructing
pages, the client would be forced to retrieve all pages before
sorting the members, which would defeat the purpose of pagination.
@@ -1127,7 +1195,7 @@
<p>The Linked Data Platform does not define how clients
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
- <div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
+ <div id="ldpc-5_2_1" class="rule">5.2.1 <a title="LDP server">LDP servers</a> MUST also be conformant <a title="LDP server">LDP servers</a>. A Linked Data Platform
Container MUST also be a conformant Linked Data Platform Resource.
</div>
<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
@@ -1139,7 +1207,7 @@
will be the LDPC resource itself, but it does not have to be. The
membership predicate is also variable and will often be a predicate
from the server application vocabulary. If there is no obvious
- predicate from the server application vocabulary to use, LDPC servers
+ predicate from the server application vocabulary to use, <a title="LDP server">LDP servers</a>
SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
any kind of resource identified by its URI, LDPR or otherwise.
</div>
@@ -1187,7 +1255,7 @@
<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
</div>
- <div id="ldpc-5_2_9" class="rule">5.2.9 LDPC servers SHOULD NOT re-use URIs,
+ <div id="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs,
regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
@@ -1244,7 +1312,7 @@
or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). See also
<a href="#ldpc-5_2_3">5.2.3</a>.
</div>
- <div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
+ <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
whose subject is the page URI,
whose predicate is <code>ldp:containerSortCriteria</code>,
@@ -1318,7 +1386,7 @@
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
- the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, LDPC servers MUST
+ the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
respond with status code 201 (Created) and the <code>Location</code>
header set to the new resource’s URL. Clients shall not expect any representation in the response
entity body on a 201 (Created) response.
@@ -1331,23 +1399,23 @@
the site that implements the LDPC.
</div>
- <div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP <code>POST</code> of non-RDF representations for
+ <div id="ldpc-5_4_3" class="rule">5.4.3 <a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations for
creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for introspection
details.
</div>
- <div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
+ <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>
- <div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers MUST accept a request entity body with a request header
+ <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]].
</div>
- <div id="ldpc-5_4_6" class="rule">5.4.6 LDPC servers SHOULD use the <code>Content-Type</code> request header
+ <div id="ldpc-5_4_6" class="rule">5.4.6 <a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header
to determine the representation format when the request has an entity body. When the header is absent,
- LDPC servers MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
+ <a title="LDP server">LDP servers</a> MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
</div>
- <div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, LDPC servers MUST interpret the null relative
+ <div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
URI for the subject of triples in the LDPR representation in the
request entity body as referring to the entity in the request body.
Commonly, that entity is the model for the “to be created” LDPR, so
@@ -1355,32 +1423,32 @@
triples in the created resource whose subject is the created
resource.
</div>
- <div id="ldpc-5_4_8" class="rule">5.4.8 LDPC servers SHOULD assign the subject URI for the resource to be
+ <div id="ldpc-5_4_8" class="rule">5.4.8 <a title="LDP server">LDP servers</a> SHOULD assign the subject URI for the resource to be
created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
</div>
- <div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
+ <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.
</div>
- <div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers MAY allow clients to suggest the URI for a resource
+ <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
no new requirements to this usage, so its presence functions as a client hint to the server
providing a desired string to be incorporated into the server's final choice of resource URI.
</div>
- <div id="ldpc-5_4_11" class="rule">5.4.11 LDPC servers that allow member creation via <code>POST</code>
+ <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>.
</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
- 201-Created and URI indicated by <code>Location</code> response header), LDPC servers MAY create an associated LDPR
+ 201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated LDPR
to contain data about the created resource. If an LDPC server creates this associated LDPR it MUST indicate
its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
</div>
- <div id="ldpc-5_4_13" class="rule">5.4.13 LDPC servers that support <code>POST</code> MUST
+ <div id="ldpc-5_4_13" class="rule">5.4.13 <a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
responses, listing post document media type(s) supported by the server.
LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
@@ -1414,11 +1482,11 @@
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>;
+ <div id="ldpc-5_5_1" class="rule">5.5.1 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>;
if the server receives such a request, it SHOULD respond with a 409
(Conflict) status code.
</div>
- <div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using
+ <div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
and <code>ldp:membershipPredicateInverse</code>.
@@ -1426,13 +1494,13 @@
use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
</div>
- <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
+ <div id="ldpc-5_5_3" class="rule">5.5.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> requests
with member resource information in the request representation.
See section <a href="#ldpc-member_data">5.1.1 Container
Member Information</a> for additional details.
</div>
- <div id="ldpc-5_5_4" class="rule">5.5.4 LDPC servers that allow member creation via <code>PUT</code>
+ <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>.
</div>
@@ -1471,7 +1539,7 @@
<section id="ldpc-HTTP_HEAD">
<h2>HTTP HEAD</h2>
<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
- <code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPC servers must also include HTTP headers
+ <code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
Thus, implementers supporting <code>HEAD</code> should also carefully read the
<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
@@ -1483,7 +1551,7 @@
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
+ <div id="ldpc-5_8_1" class="rule">5.8.1 <a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
method for updating LDPC non-membership properties.
</div>
</section>
@@ -1494,14 +1562,14 @@
</p>
<div id="ldpc-5_9_1" class="rule">5.9.1
- LDPC servers SHOULD define a corresponding
+ <a title="LDP server">LDP servers</a> SHOULD define a corresponding
<a>non-member resource</a>
to support requests for information about a LDPC
without retrieving a full representation including all of its members;
see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
examples.
In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>,
- LDPC servers that define a non-member resource SHOULD provide an HTTP <code>Link</code>
+ <a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
header whose target URI is the <a>non-member resource</a>, and whose link relation type is
<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.
@@ -1533,7 +1601,8 @@
<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
<ul>
<li>The addition of <a>Accept-Post</a> in this specification is pending
- advancement of an IETF draft that would fully include it, see [[!RFC5789]]. Once LDP is in
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
+ that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]]. Once LDP is in
Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
working with the W3C Director.</li>
</ul>
@@ -1541,7 +1610,7 @@
<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
- It is modeled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
+ It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
</p>
<div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
@@ -1588,6 +1657,39 @@
</section>
</section> <!-- Header defns -->
+<section id="ldpclient">
+<h1>Linked Data Platform Clients</h1>
+<div class="ldp-issue-open">
+
+
+<p>All of the following rules are just copied here, without change; still need to be removed from original section.
+Should consider making this section come before the server sections; doing so would cause mass-renumbering however.
+</p>
+ <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+ </div>
+ <div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
+ of a given LDPR can change over time.
+ </div>
+ <div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
+ resource of a particular type at an arbitrary server is open, in the
+ sense that different resources of the same type may not all have the
+ 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.
+ </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
+ its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
+ <code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
+ [[RFC5789]].
+ </div>
+
+</div>
+</section> <!-- Client constraints -->
+
+
<section class='appendix informative'>
<h2>Acknowledgements</h2>
@@ -1612,6 +1714,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> -->
<ul>
+ <li>2013-10-01 - Conformance section drafting (JA)</li>
<li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
<li>2013-09-17 - Change must to MUST in <a href="#ldpc-5_6_4">5.6.4</a> (SS)</li>
<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>