--- a/ldp.html Thu Jan 02 13:59:20 2014 -0500
+++ b/ldp.html Wed Jan 22 12:09:38 2014 -0500
@@ -31,7 +31,8 @@
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
- <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
+ <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
+ <!-- <script src='file:///Users/sspeiche/git/respec/js/profile-w3c-common.js' class='remove' async></script> -->
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
@@ -62,6 +63,9 @@
// if this is a LCWD, uncomment and set the end of its review period
lcEnd: "2013-09-02",
+
+ // Only include h1 and h2 level
+ maxTocLevel: 0, // HACK: We want 2 but auto-numbering doesn't happen
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
@@ -189,7 +193,8 @@
background: #fff;
padding: 3px 1em;
}
-
+ .normal { font-weight: normal; }
+
</style>
<style type="text/css" media="all">
code {
@@ -444,6 +449,40 @@
</section>
+<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>
+<section><h2>General</h2>
+ <section id="ldp-cli-multitype"><h2 class="normal">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>.
+ </h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
+
+ <section id="ldpr-cli-typeschange"><h2 class="normal">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.
+ </h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
+
+ <section id="ldpr-cli-openpreds"><h2 class="normal"><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.
+ </h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
+
+ <section id="ldpr-cli-preservetriples"><h2 class="normal">A <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]].
+ </h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
+</section>
+</section> <!-- Client constraints -->
<section id="ldpr">
<h1>Linked Data Platform Resources</h1>
@@ -490,65 +529,44 @@
<section id="ldpr-general">
<h2>General</h2>
- <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.
+ <section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
+ </h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
+
+ <section id="ldpr-gen-rdf"><h2 class="normal"><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 <a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
+ </h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
+
+ <section id="ldpr-gen-binary"><h2 class="normal"><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>
+ that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
- <div id="ldpr-4_2_4" class="rule">4.2.4 LDPRs SHOULD reuse existing vocabularies instead of creating
+ <section id="ldpr-gen-reusevocab"><h2 class="normal">LDPRs SHOULD reuse existing vocabularies instead of creating
their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
covered by other conformance rules.
- </div>
- <div id="ldpr-4_2_4_1" class="rule">4.2.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+ </h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
+
+ <section id="ldpr-gen-reusevocabsuchas"><h2 class="normal">LDPR predicates SHOULD use standard vocabularies such as Dublin Core
[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
- </div>
- <div id="ldpr-4_2_5" class="rule">4.2.5 LDPR representations SHOULD have at least one <code>rdf:type</code>
+ </h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+
+ <section id="ldpr-gen-atleast1rdftype"><h2 class="normal">LDPR representations SHOULD have at least one <code>rdf:type</code>
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <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.
- </div>
- -->
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
- this document, for example through application-specific means, SPARQL
- 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 <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>
- <!-- Action-110 removed this 2013-10-25
- <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 <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
- more complex constraints will greatly restrict the set of clients
- 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 <a title="LDP server">LDP servers</a>
+ </h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
+
+ <section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either
+ weak or strong ones) as response <code>ETag</code> header values.
+ </h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
+
+ <section id="ldpr-gen-linktypehdr"><h2 class="normal"><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 LDPR's HTTP <code>Request-URI</code>.
- </div>
+ </h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
<blockquote>
<p>
Note:
@@ -558,28 +576,32 @@
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,
+ it asserts that the resource <a href="#ldpr-gen-tags">has Etags</a>, <a href="#ldpr-gen-rdf">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
+ <a href="#ldpr-gen-binary">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, 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>
+
+ <section id="ldpr-gen-noinferencing"><h2 class="normal"><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 <a title="LDP server">LDP servers</a> MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
+ </h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
+
+ <section id="ldpr-gen-defbaseuri"><h2 class="normal"><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>
- <div id="ldpr-4_2_13" class="rule">4.2.13 <a title="LDP server">LDP servers</a> MUST
+ </h2></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
+
+ <section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
publish any constraints on <a title="LDP client">LDP clients’</a> ability to
create or update LDPRs, by adding a Link header with <code>rel='describedby'</code>
[[!POWDER-DR]] to all responses to requests which fail due to violation of
@@ -591,42 +613,41 @@
as stated in [[POWDER-DR]], the target might (or might not) be a POWDER
document. Natural language constraint documents are therefore permitted,
although machine-readable ones facilitate better client interactions.
- </div>
- <div id="ldpr-page-large" class="rule">4.2.14 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
+ </h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
+
+ <section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
pages.
See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
- </div>
- <div id="ldpr-split-any" class="rule">4.2.15 <a title="LDP server">LDP servers</a> MAY
+ </h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+
+ <section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>.
See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
- </div>
+ </h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
</section>
<section id="ldpr-HTTP_GET">
<h2>HTTP GET</h2>
- <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 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in
+ <section id="ldpr-get-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
+ </h2></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
+
+ <section id="ldpr-get-options"><h2 class="normal"><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 <a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
+ </h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
+
+ <section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
representation of the requested LDPR [[!TURTLE]].
- </div>
- <!-- Action-108 removed this 2013-10-22
- <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,
+ </h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+ <section id="ldpr-get-multitypes"><h2 class="normal">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,
+ </h2></section><!-- Was 4.3.5 / #ldpr-4_3_5 -->
+
+ <section id="ldpr-get-typeschange"><h2 class="normal">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>
+ </h2></section><!-- Was 4.3.6 / #ldpr-4_3_6 -->
</section>
<section id="ldpr-HTTP_POST">
@@ -638,7 +659,7 @@
<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those
sections for more details. Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
<!-- TODO: movethis content into an intro/overview section and add PATCH. -->
</p>
</section>
@@ -649,10 +670,10 @@
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.
Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <div id="ldpr-4_5_1" class="rule">4.5.1 If a HTTP <code>PUT</code> is accepted on an existing resource,
+ <section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted 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.
@@ -662,9 +683,9 @@
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>
+ </h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
- <div id="ldpr-4_5_1_1" class="rule">4.5.1.1
+ <section id="ldpr-put-servermanagedprops"><h2 class="normal">
If an otherwise valid HTTP <code>PUT</code> request is received
that attempts to change triples the server does not allow clients to modify,
<a title="LDP server">LDP servers</a> MUST
@@ -674,14 +695,14 @@
information about which triples could not be
persisted.
The format of the 4xx response body is not constrained by LDP.
- </div>
+ </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
<blockquote>
Informative note: Clients might provide triples equivalent to those already in the resource's state,
e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
server-controlled triples are identical on the GET response and the subsequent PUT request.
</blockquote>
- <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>
+ <section id="ldpr-put-precond"><h2 class="normal"><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. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
@@ -689,8 +710,9 @@
(Condition Failed) if <code>ETag</code>s fail to match when there are no other
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 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
+ </h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
+
+ <section id="ldpr-put-openpreds"><h2 class="normal"><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
@@ -698,8 +720,9 @@
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
+ </h2></section><!-- Was 4.5.3 / #ldpr-4_5_3 -->
+
+ <section id="ldpr-put-failed"><h2 class="normal">
If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
chooses not to persist, e.g. unknown content,
<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
@@ -709,19 +732,22 @@
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
+ </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+
+ <section id="ldpr-put-perserveall"><h2 class="normal">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 <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 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
+ </h2></section><!-- Was 4.5.5 / #ldpr-4_5_5 -->
+
+ <section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ </h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
+
+ <section id="ldpr-put-simpleupdate"><h2 class="normal"><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 enable simple creation and modification of LPDRs.
- </div>
+ </h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
</section>
<section id="ldpr-HTTP_DELETE">
@@ -730,24 +756,6 @@
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>
<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>
-
- <!-- Action-108 removed this 2013-10-22
- <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>
- -->
-
- <!-- Action-108 removed this 2013-10-22
- <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 <a title="LDP server">LDP servers</a> to
- not do this – behavior is server application specific.
- </div>
- -->
</section>
<section id="ldpr-HTTP_HEAD">
@@ -756,7 +764,8 @@
<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 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.</div>
+ <section id="ldpr-head-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.
+ </h2></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
</section>
<section id="ldpr-HTTP_PATCH">
@@ -765,21 +774,17 @@
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.
Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <!-- Action-108 removed this 2013-10-22
- <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_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>.
+
+ <section id="ldpr-patch-create"><h2 class="normal"><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="#ldpr-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 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
+ </h2></section><!-- Was 4.8.3 / #ldpr-4_8_3 -->
+
+ <section id="ldpr-patch-acceptpatch"><h2 class="normal"><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>
+ </h2></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->
</section>
@@ -793,11 +798,13 @@
add other requirements on <code>OPTIONS</code> responses.
</p>
- <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
+ <section id="ldpr-options-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.
+ </h2></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
+
+ <section id="ldpr-options-allow"><h2 class="normal"><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>
+ </h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
</section>
@@ -903,7 +910,7 @@
</pre>
<p>
In this example, there are only two customers provided in the
- final page. To indicate this is the last page, the server omits the <code>Link rel='next'</code>
+ final page. To indicate this is the last page, the server omits the <code>Link: rel='next'</code>
header in its response.
</p>
<p>
@@ -922,11 +929,11 @@
and their associated <a title="Single-page resource">single-page resources</a>.
</p>
- <div id="ldpr-pagingGET-sequences-change" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MAY
+ <section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
add <a title="Single-page resource">single-page resources</a> to a
<a title="Paged resource">paged resource's</a> sequence over time,
but SHOULD only add pages to the end of a sequence.
- </div><div class="rule">
+ </h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
<blockquote>Informative note:
As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
change as the state of the <a title="Paged resource">paged resource</a> changes.
@@ -935,103 +942,59 @@
server A might host the initial portion of a sequence that links to the last page server A is aware of,
hosted on server B, and server B might extend the sequence of pages.
</blockquote>
- </div>
- <!-- Removed - action-113
- <div id="ldpr-pagingGET-first-reqd-onbase" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MAY
- provide an HTTP <code>Link</code>
- header whose target URI is the <em>first</em> <a title="Single-page resource">single-page resource</a>, and whose link relation type is <code>first</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the first page.
- For example, if there is a LDPR with URL <code><resourceURL></code> that supports paging and whose
- first page URL is <code><resourceURL>?theFirstPage</code>, then the corresponding link header
- would be <code>Link: <?theFirstPage>;rel='first'</code>.
- If no such <code>Link</code> header is present,
- then clients have no LDP-defined way to discover that the resource supports paging or the
- URI of the first page.
- </div>
- -->
- <div id="ldpr-pagingGET-first-allowed-onpages" class="rule">4.10.2.1.1
- <a title="LDP server">LDP servers</a> MAY provide
- a <a>first page link</a> when responding to
- requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- </div>
- <div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 removed
- </div>
- <!-- Removed - action-113
- <div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 <a title="LDP server">LDP servers</a> MAY
- provide an HTTP <code>Link</code>
- header whose target URI is the final <a title="Single-page resource">single-page resource</a>,
- and whose link relation type is <code>last</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code> and/or
- requests with a <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the final page without
- following a potentially long sequence of next links.
- If no such <code>Link</code> header is present,
- then clients can only find the final page using LDP-defined means
- by following the <code>next</code> links to the end.
- </div>
- -->
- <div id="ldpr-pagingGET-last-allowed-onpages" class="rule">4.10.2.1.3 <a title="LDP server">LDP servers</a> MAY
- provide a <a>last page link</a>
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- </div>
- <div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MUST
+
+ <section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
+ <a title="LDP server">LDP servers</a> MAY provide
+ a <a>first page link</a> when responding to
+ requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ </h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+
+ <section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ provide a <a>last page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ </h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+ </section>
+
+ <section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
provide a <a>next page link</a>
in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
<em>other than the final page</em>
as the <code>Request-URI</code>.
This is the mechanism by which clients can discover the URL of the next page.
- </div>
- <div id="ldpr-pagingGET-lastnext-prohibited" class="rule">4.10.2.2.1 <a title="LDP server">LDP servers</a> MUST NOT
- provide a <a>next page link</a>
- in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the end of the page sequence
- as currently known by the server.
- </div>
- <div id="ldpr-pagingGET-prev-allowed" class="rule">4.10.2.2.2 <a title="LDP server">LDP servers</a> MAY
- provide a <a>previous page link</a>
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
- <em>other than the first page</em>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the URL of the previous page.
- </div>
- <div id="ldpr-pagingGET-firstprev-prohibited" class="rule">4.10.2.2.3 <a title="LDP server">LDP servers</a> MUST NOT
- provide a <a>previous page link</a>
- in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the beginning of the page sequence
- as currently known by the server.
- </div>
- <div id="ldpr-pagingGET-collection-reqd" class="rule">4.10.2.2.4 removed
- </div>
- <!-- Removed - action-113
- <div id="ldpr-pagingGET-collection-reqd" class="rule">4.10.2.2.4 <a title="LDP server">LDP servers</a> MUST
- provide an HTTP <code>Link</code>
- header whose target URI is the <a title="Paged resource">paged resource</a>, and whose link relation type is <code>collection</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the resource whose representation
- has been broken into pages, in cases where some other actor gives the client
- a <a title="Single-page resource">single-page resource</a> URL.
- </div>
- -->
- <div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 removed
- </div>
- <!-- Removed - action-113
- <div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a>
- that initiate paging for a LDPR MUST respond
- by returning the first page resource using a <code>209 Related Content</code> response
- with an HTTP <code>Location</code> header providing the first <a title="Single-page resource">single-page resource</a> URL.
- </div>
- -->
- <div id="ldpr-pagingGET-page-type-reqd" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> MUST
+ </h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+
+ <section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a>next page link</a>
+ in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the end of the page sequence
+ as currently known by the server.
+ </h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+
+ <section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ provide a <a>previous page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ <em>other than the first page</em>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the URL of the previous page.
+ </h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+
+ <section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a>previous page link</a>
+ in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the beginning of the page sequence
+ as currently known by the server.
+ </h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+ </section>
+
+ <section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
provide an HTTP <code>Link</code>
header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
as the <code>Request-URI</code>.
This is one mechanism by which clients know that the resource is one of a sequence of pages.
- </div>
+ </h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
</section>
<section id="ldpr-paging-HTTP_OPTIONS">
@@ -1047,15 +1010,6 @@
This lowers server implementation effort.
</p>
- <div id="ldpr-4_10_3_1" class="rule">4.10.3.1 removed
- </div>
- <!-- Removed - action-113
- <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
- providing a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to HTTP <code>OPTIONS</code>
- requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
- </div>
- -->
-
</section> <!-- h3 -->
</section> <!-- h2 -->
@@ -1235,9 +1189,8 @@
triples whose subject is the LDPC resource itself.
</p>
-
- <div id="ldpc-get_non-member_props" class="rule">5.1.1 Retrieving Only Non-member Properties
- </div>
+ <section id="ldpc-get_non-member_props"><h2 class="normal">Retrieving Only Non-member Properties
+ </h2><!-- Was 5.1.1 / #ldpc-get_non-member_props -->
<p>The representation of a container
that has many members will be large. There are several important
cases where clients need to access only the non-member properties of
@@ -1284,8 +1237,10 @@
<p>While the same non-member resource could be used to update the non-member properties via PUT,
LDP recommends using PATCH for this purpose.</p>
+
+ </section><!-- ldpc-get_non-member_props -->
- <div id="ldpc-ordering" class="rule">5.1.2 Ordering</div>
+ <section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
<p>
There are many cases where an ordering of the members of the
container is important. LDPC does not provide any particular support
@@ -1372,6 +1327,7 @@
the ordering approach doesn't change as containers themselves are LDPRs and the
properties from the domain model can be leveraged for the sort criteria.
</p>
+ </section><!-- Was 5.1.2 / #ldpc-ordering -->
</section>
<section id="ldpc-general">
@@ -1379,15 +1335,11 @@
<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
- Each Linked Data Platform Container MUST also be a conforming Linked Data Platform Resource.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
- (LDPR or not) MAY be a member of more than one LDPC.
- </div>
- -->
- <div id="ldpc-5_2_3" class="rule">5.2.3 <a title="LDP server">LDP servers</a>
+ <section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Container MUST also be
+ a conforming Linked Data Platform Resource.
+ </h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
+
+ <section id="ldpc-mbrpred"><h2 class="normal"><a title="LDP server">LDP servers</a>
SHOULD use the <code>rdfs:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
if there is no obvious predicate from an application vocabulary to use.
The state of an LDPC includes information about which
@@ -1399,88 +1351,56 @@
occurs in the <a title="Membership triples">membership triples</a>.
Member resources can be
any kind of resource identified by a URI, LDPR or otherwise.
- </div>
- <div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain exactly one triple
+ </h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
+
+ <section id="ldpc-containres"><h2 class="normal">An LDPC representation MUST contain exactly one triple
whose subject is the LDPC URI,
whose predicate is the <code>ldp:containerResource</code>,
and whose object is the LDPC's membership-constant-URI.
Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this.
- </div>
- <div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain exactly one triple
+ </h2></section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
+
+ <section id="ldpc-containtriples"><h2 class="normal">An LDPC representation MUST contain exactly one triple
whose subject is the LDPC URI,
and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>.
The object of the triple is constrained by other sections, such as
- <a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>, based on the
+ <a href="#ldpc-containtriple-relation" class="sectionRef">ldp:containsRelation</a> or
+ <a href="#ldpc-containtriple-byrelation" class="sectionRef">ldp:containedByRelation</a>, based on the
<a title="Membership triples">membership triple</a>
pattern used by the container.
- </div>
- <div id="ldpc-5_2_5_1" class="rule">5.2.5.1 LDPCs whose <a title="Membership triples">membership triple</a>
+ </h2><!-- Was 5.2.5 / #ldpc-5_2_5 -->
+
+ <section id="ldpc-containtriple-relation"><h2 class="normal">LDPCs whose <a title="Membership triples">membership triple</a>
pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
contain exactly one triple
whose subject is the LDPC URI,
whose predicate is either <code>ldp:containsRelation</code>,
and whose object is the URI of <var>membership-predicate</var>.
- </div>
- <!-- Action-112 rewrote this 2013-11-12, original in this comment
- <div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
- of the LDPC and predicate of
- <code>ldp:containsRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containsRelation</code>, <var>P)</var>.
- For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
- same subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
- (<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
- a member resource.
- </div>
- -->
- <div id="ldpc-5_2_5_2" class="rule">5.2.5.2 LDPCs whose <a title="Membership triples">membership triple</a>
+ </h2></section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
+
+ <section id="ldpc-containtriple-byrelation"><h2 class="normal">LDPCs whose <a title="Membership triples">membership triple</a>
pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
contain exactly one triple
whose subject is the LDPC URI,
whose predicate is either <code>ldp:containedByRelation</code>,
and whose object is the URI of <var>membership-predicate</var>.
- </div>
- <!-- Action-112 rewrote this 2013-11-12, original in this comment
- <div id="ldpc-5_2_5_2" class="rule">5.2.5.2 For a given triple <var>T</var> with a subject <var>C</var>
- of the LDPC and predicate of
- <code>ldp:containedByRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containedByRelation</code>, <var>P)</var>.
- For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
- object subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
- (<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
- a member resource.
- </div>
- -->
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
- additional triples whose subjects are the members of the container,
- or that are from the representations of the members (if they have RDF
- representations). This allows a LDPC server to provide clients with
- information about the members without the client having to do a <code>GET</code>
- on each member individually. See <a href="#ldpc-member_data">section 5.1.1 Container
- Member Information</a> for additional details.
- </div>
- -->
- <div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have an <code>rdf:type</code>
+ </h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
+ </section>
+
+ <section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MUST have an <code>rdf:type</code>
of <code>ldp:Container</code>. Informative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
might have additional types</a>, like any RDF resource.
- </div>
- <div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+ </h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <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]].
- While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
- scenarios, re-using URIs creates ambiguities for clients that are best avoided.
- </div>
- -->
- <div id="ldpc-5_2_10" class="rule">5.2.10 LDPCs MUST contain one triple whose
+ </h2></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
+
+ <section id="ldpc-indirectmbr"><h2 class="normal">LDPCs MUST contain one triple whose
subject is the LDPC URI,
whose predicate is <code>ldp:insertedContentRelation</code>, and
whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in
- the container's <a title="Membership triples">membership triples</a> is chosen.
+ the container's <a title="Membership triples">membership triples</a> is chosen.</h2>
<ul>
<li>
LDP defines the URI <code>ldp:MemberSubject</code> for the common case where
@@ -1493,7 +1413,7 @@
</li>
<li>
In other cases, the <var>member-derived-URI</var> is taken from some triple
- <var>( S, P, O)</var> in the document supplied by the client as input to the create request;
+ <var>( S, P, O )</var> in the document supplied by the client as input to the create request;
if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
<var>O</var>. LDP does not define the behavior when more than one triple containing
the predicate <var>P</var> is present in the client's input.
@@ -1504,28 +1424,7 @@
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]].
- To determine which member URI to use as the <var>member-derived-URI</var>
- in the membership triple, LDPCs MUST contain one triple whose
- subject is the LDPC URI, whose predicate is <code>ldp:insertedContentRelation</code>, and whose object is <var>MO</var>.
- <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create
- (as found in HTTP response <code>Location</code> header) are
- used to locate a triple in <var>R</var> of the form <var>(R, MO, N)</var>.
- When the LDPC uses <code>ldp:containsRelation</code>,
- <var>N</var> is then used to construct the membership triple of the form:
- <var>(membership consistent value, membership predicate, N)</var>.
- When the LDPC uses <code>ldp:containedByRelation</code>,
- the membership triple is
- of the form: <var>(N, membership predicate, membership consistent value)</var>.
- To indicate that the member resource URI is the membership object
- (the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code>
- such that it forms the triple:
- <var>(LDPC URI, <code>ldp:insertedContentRelation</code>, <code>ldp:MemberSubject</code>)</var>.
- </div>
- -->
+ </section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
@@ -1552,30 +1451,31 @@
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>
+ <section id="ldpc-linktypehdr"><h2 class="normal"><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
+ The <a href="#ldpr-gen_linktypehdr">notes on the corresponding LDPR constraint</a> apply
equally to LDPCs.
- </div>
+ </h2></section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
</section>
<section id="ldpc-HTTP_GET">
<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
+ <section id="ldpc-get-mbrtriples"><h2 class="normal">The representation of a LDPC MUST contain a set of
<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
- <a href="#ldpc-5_2_3">5.2.3</a>.
- </div>
- <div id="ldpc-5_3_2" class="rule">5.3.2 <a title="LDP server">LDP servers</a> MAY
+ section on <a href="#ldpc-mbrpred">LDPC membership predicates</a>.
+ </h2></section><!-- Was 5.3.1 / #ldpc-5_3_1 -->
+
+ <section id="ldpc-sortcriteriaobj"><h2 class="normal"><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 specify the order using a triple
whose subject is the page URI,
@@ -1591,10 +1491,11 @@
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.2 Ordering</a> for
+ See section <a href="#ldpc-ordering" class="sectionRef"></a> for
an example.
- </div>
- <div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations
+ </h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
a triple
@@ -1606,25 +1507,29 @@
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.
- </div>
- <div id="ldpc-5_3_4" class="rule">5.3.4 LDPC page representations
+ </h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+
+ <section id="ldpc-sortorder"><h2 class="normal">LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
a triple
whose subject is the sort criterion identifier,
whose predicate is <code>ldp:containerSortOrder</code>
- and whose object describes the order used. LDP defines two values,
+ and whose object describes the order used.
+ LDP defines two values,
<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
as the object of this triple. Other values can be used, but LDP
assigns no meaning to them and interoperability will be limited.
- </div>
- <div id="ldpc-5_3_5" class="rule">5.3.5 LDPC page representations
+ </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
+
+ <section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MAY contain,
in any <code>ldp:containerSortCriterion</code> list entry,
a triple
whose subject is the sort criterion identifier,
whose predicate is <code>ldp:containerSortCollation</code>
- and whose object identifies the collation used. LDP defines no values for use
+ and whose object identifies the collation used.
+ LDP defines no values for use
as the object of this triple. While it is better for interoperability to use
open standardized values, any value can be used.
When the <code>ldp:containerSortCollation</code> triple is absent and the
@@ -1641,7 +1546,7 @@
specified collation.
The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
- </div>
+ </h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
</section>
<section id="ldpc-HTTP_POST">
@@ -1650,83 +1555,87 @@
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.
Any server-imposed constraints on creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
+ <section id="ldpc-post-created201"><h2 class="normal">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, <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.
- </div>
+ </h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
- <div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
+ <section id="ldpc-post-createdmbr"><h2 class="normal">After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
appear as a member of the LDPC until the new resource is deleted or
removed by other methods. An LDPC MAY also contain resources that were
added through other means - for example through the user interface of
the site that implements the LDPC.
- </div>
+ </h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
- <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
+ <section id="ldpc-post-createbins"><h2 class="normal"><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-post-acceptposthdr">AcceptPost section</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 <a title="LDP server">LDP servers</a> that successfully create a new resource from a
+ </h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
+
+ <section id="ldpc-post-createrdf"><h2 class="normal"><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>
+ </h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
<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>If the request header <a href="#ldpr-gen-linktypehdr">specifies an LDPR interaction model</a>, then the server MUST create an LDPR.</li>
+ <li>If the request header <a href="#ldpc-linktypehdr">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>
+ </section>
- <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
+ <section id="ldpc-post-turtle"><h2 class="normal"><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 <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.
- <!-- Action-108 removed this 2013-10-22
- When the header is absent,
- <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, <a title="LDP server">LDP servers</a> MUST interpret the null relative
+ </h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
+
+ <section id="ldpc-post-contenttype"><h2 class="normal"><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.
+ </h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
+
+ <section id="ldpc-post-rdfnullrel"><h2 class="normal">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
triples whose subject is the null relative URI will usually result in
triples in the created resource whose subject is the created
resource.
- </div>
- <div id="ldpc-5_4_8" class="rule">5.4.8 <a title="LDP server">LDP servers</a> SHOULD assign the 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 <a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
+ </h2></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->
+
+ <section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
+ created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
+ </h2></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
+
+ <section id="ldpc-post-mincontraints"><h2 class="normal"><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 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
+ </h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
+
+ <section id="ldpc-post-slug"><h2 class="normal"><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>
+ </h2></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
- <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>
+ <section id="ldpc-post-dontreuseuris"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code>
SHOULD NOT re-use URIs.
- </div>
+ </h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
- <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
+ <section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">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), <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 <a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
+ </h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
+
+ <section id="ldpc-post-acceptposthdr"><h2 class="normal"><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
@@ -1740,9 +1649,9 @@
that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
specifications such as LDP.
- </div>
+ </h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
- <div id="ldpc-5_4_14" class="rule">5.4.14 LDPCs that create new member resources MAY add triples to the container
+ <section id="ldpc-post-ldpcreated"><h2 class="normal">LDPCs that create new member resources MAY add triples to the container
as part of member creation to reflect its factory role.
LDP defines the <code>ldp:created</code> predicate for this purpose.
An LDPC that tracks members created through the LDPC MUST add a triple to the container
@@ -1750,9 +1659,9 @@
whose predicate is <code>ldp:created</code>, and
whose object is the newly created member resource's URI;
it MAY add other triples as well.
- </div>
+ </h2></section><!-- Was 5.4.14 / #ldpc-5_4_14 -->
- <div id="ldpc-5_4_15" class="rule">5.4.15 LDPCs
+ <section id="ldpc-post-indirectmbrrel"><h2 class="normal">LDPCs
whose <code>ldp:insertedContentRelation</code> triple has an object
<strong>other than</strong> <code>ldp:MemberSubject</code>
and that create new resources
@@ -1760,10 +1669,10 @@
whose subject is the container's URI,
whose predicate is <code>ldp:created</code>, and
whose object is the newly created resource's URI (which will be different from
- the <var><a href="#ldpc-5_2_10">member-derived URI</a></var> in this case).
+ the <var><a href="#ldpc-indirectmbr">member-derived URI</a></var> in this case).
This <code>ldp:created</code> triple can be the only link from the container to the newly created
resource in certain cases.
- </div>
+ </h2></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
</section>
@@ -1773,27 +1682,25 @@
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.
Any server-imposed constraints on creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <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>;
+ <section id="ldpc-put-mbrprops"><h2 class="normal"><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 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
+ </h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
+
+ <section id="ldpc-put-nonmbrprops"><h2 class="normal"><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:containerResource</code>, <code>ldp:containsRelation</code>
and <code>ldp:containedByRelation</code>.
The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
- </div>
+ </h2></section><!-- Was 5.5.2 / #ldpc-5_5_2 -->
- <div id="ldpc-5_5_3" class="rule">5.5.3 removed - inlining
- </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>
+ <section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code>
SHOULD NOT re-use URIs.
- </div>
+ </h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
</section>
@@ -1803,30 +1710,33 @@
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_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
+ <section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose representation
was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
(for example, the member is managed by the same server), the LDPC server MUST also remove it from
the LDPC by removing the corresponding membership triple.
- </div>
- <div id="ldpc-5_6_2" class="rule">5.6.2 When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
+ </h2></section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
+
+ <section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
on a LDPC member resource, it MUST remove any
membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
- </div>
+ </h2>
<blockquote>
Informative note: The <a>LDP server</a> might perform additional removal
of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
been accessed for some period of time.
</blockquote>
- <div id="ldpc-5_6_3" class="rule">5.6.3 When the conditions in <a href="#ldpc-5_6_1">5.6.1</a> hold, and the LDPC tracks member
+ </section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+
+ <section id="ldpc-del-ldpcreated"><h2 class="normal">When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member
resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove
the deleted member's <code>ldp:created</code> triple.
- </div>
+ </h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
- <div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose
+ <section id="ldpc-del-contremovesmbrres"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose
representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server
- created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server MUST also remove the associated LDPR it created.
- </div>
+ created an associated LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDPR it created.
+ </h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
</section>
@@ -1846,12 +1756,12 @@
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.
Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <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
+ <section id="ldpc-patch-req"><h2 class="normal"><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>
+ </h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>
<section id="ldpc-HTTP_OPTIONS">
@@ -1859,14 +1769,13 @@
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
</p>
- <div id="ldpc-5_9_1" class="rule">5.9.1
+ <section id="ldpc-options-nonmbrprops"><h2 class="normal">
<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;
- <!-- sectionref this -->
- see section <a href="#ldpc-get_non-member_props">5.1.1 Retrieving Only Non-member Properties</a> for
- examples.
+ see section <a href="#ldpc-get_non-member_props" class="secitonRef"></a> for
+ examples.</h2>
In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</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
@@ -1879,11 +1788,11 @@
non-member resource
URL is <code><containerURL>?nonMemberProperties</code>, then the corresponding link header
would be <code>Link: <?nonMemberProperties>;rel='http://www.w3.org/ns/ldp#nonMemberResource'</code>
- </div>
+ </section><!-- Was 5.9.1 / #ldpc-5_9_1 -->
- <div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose
+ <section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC 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) 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>
+ non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</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]].
@@ -1892,16 +1801,9 @@
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>
+ </h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
</section> <!-- h2 -->
</section> <!-- h1 -->
@@ -1928,17 +1830,17 @@
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
- the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:
+ <section id="header-accept-post-1"><h2 class="normal">The syntax for <code>Accept-Post</code>, using
+ the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:</h2>
<blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
<p>
The <code>Accept-Post</code> header specifies a comma-separated list of media-
types (with optional parameters) as defined by [[!HTTP11]], Section 3.7.
</p>
</blockquote>
- </div>
+ </section><!-- Was 6.1.1 / #header-accept-post-1 -->
- <div id="header-accept-post-2" class="rule">6.1.2
+ <section id="header-accept-post-2"><h2 class="normal">
The <code>Accept-Post</code> HTTP header SHOULD appear in the <code>OPTIONS</code> response for any resource
that supports the use of the <code>POST</code> method. The presence of the
<code>Accept-Post</code> header in response to any method is an implicit
@@ -1946,9 +1848,9 @@
<code>Request-URI</code>. The presence of a specific document format in
this header indicates that that specific format is allowed on <code>POST</code> requests to the
resource identified by the <code>Request-URI</code>.
- </div>
+ </h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
- <div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
+ <section id="header-accept-post-iana" ><h2 class="normal">IANA Registration Template</h2>
<div>
<blockquote>
<p>
@@ -1968,6 +1870,7 @@
</p>
</blockquote>
</div>
+ </section><!-- Was 6.1.3 / #header-accept-post-iana -->
</section>
</section> <!-- Header defns -->
@@ -2046,38 +1949,6 @@
</section>
</section> <!-- status code 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 A <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 id="base-specs" class="informative">
<h1>Notable information from normative references</h1>
@@ -2095,22 +1966,23 @@
For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
experience has shown that few non-experts find all of them obvious. This section enumerates these topics;
it is simply re-stating (informatively) information locatable via the normative references.
-</p>
+</p></div>
<section id="specs-webarch" class="informative">
<h1>Architecture of the World Wide Web</h1>
Reference: [[!WEBARCH]]
- <div id="ldp-webarch-nonexcl-membership" class="rule">9.1.1 LDPC membership is not exclusive; this means that the same resource
+ <section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
(LDPR or not) can be a member of more than one LDPC.
- </div>
- <div id="ldp-webarch-uri-reuse" class="rule">9.1.2 <a title="LDP server">LDP servers</a> should not re-use URIs,
+ </h2></section>
+
+ <section id="ldp-webarch-uri-reuse"><h2 class="normal"><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 might delete a resource and then later re-use the
URI when it identifies the same resource, but only when consistent with Web architecture.
While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
scenarios, re-using URIs creates ambiguities for clients that are best avoided.
- </div>
+ </h2></section>
</section>
@@ -2118,41 +1990,45 @@
<h1>HTTP 1.1</h1>
Reference: [[!HTTP11]]
- <div id="ldp-http-other-representations" class="rule">9.2.1 <a title="LDP server">LDP servers</a> can support representations beyond those
+ <section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support 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.
HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
- </div>
- <div id="ldp-http-other-methods" class="rule">9.2.2 LDPRs can be created, updated and deleted using methods not defined in
+ </h2></section>
+
+ <section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
this document, for example through application-specific means, SPARQL
UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
normative requirements.
- </div>
- <div id="ldp-http-delete-uri-reuse" class="rule">9.2.3 <a title="LDP server">LDP servers</a>
+ </h2></section>
+
+ <section id="ldp-http-delete-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a>
remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
After such a request, a subsequent HTTP <code>GET</code> on the same
<code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
code, although HTTP allows others.
- </div>
+ </h2></section>
- <div id="ldp-http-method-side-effects" class="rule">9.2.4 <a title="LDP server">LDP servers</a> can alter the state of other resources
+ <section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources
as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1).
For example, it is acceptable for the server to
remove triples from other resources whose subject or object is the
deleted resource as the result of a successful HTTP <code>DELETE</code> request.
It is also acceptable and common for <a title="LDP server">LDP servers</a> to
not do this – the server's behavior can vary, so LDP clients cannot depend on it.
- </div>
- <div id="ldp-http-patch-allowed" class="rule">9.2.5 <a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code>
+ </h2></section>
+
+ <section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code>
to allow modifications,
especially partial replacement, of their resources. No
minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
- </div>
- <div id="ldp-http-content-sniffing" class="rule">9.2.6
+ </h2></section>
+
+ <section id="ldp-http-content-sniffing"><h2 class="normal">
When the <code>Content-Type</code> request header is absent from a request,
<a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
- </div>
+ </h2></section>
</section>
@@ -2160,11 +2036,12 @@
<h1>RDF</h1>
Reference: [[RDF-CONCEPTS]]
- <div id="ldp-rdfconcepts-extra-triples-any" class="rule">9.3.1 The state of an LDPR
+ <section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal"> The state of an LDPR
can have triples with any subject(s). The URL used to retrieve the
representation of an LDPR need not be the subject of any of its triples.
- </div>
- <div id="ldp-rdfconcepts-extra-triples-members" class="rule">9.3.2 The representation of an LDPC
+ </h2></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal"> The representation of an LDPC
can include an arbitrary number of
additional triples whose subjects are the members of the container,
or that are from the representations of the members (if they have RDF
@@ -2172,10 +2049,11 @@
information about the members without the client having to do a <code>GET</code>
on each member individually. See <a href="#ldpc-member_data">Container
Member Information</a> for additional details.
- </div>
- <div id="ldp-rdfconcepts-extra-triples-types" class="rule">9.3.3 The state of an LDPR can have more than one
+ </h2></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal"> The state of an LDPR can have more than one
triple with a <code>rdf:type</code> predicate.
- </div>
+ </h2></section>
</section>
@@ -2183,15 +2061,14 @@
<h1>Feed paging and archiving</h1>
Reference: [[RFC5005]]
- <div id="ldp-paging-incomplete" class="rule">9.4.1 A <a title="LDP client">LDP client</a>
+ <section id="ldp-paging-incomplete"><h2 class="normal"> A <a title="LDP client">LDP client</a>
SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
complete, or make assumptions to that effect.
[[RFC5005]].
- </div>
+ </h2></section>
</section>
-</div>
</section> <!-- Base specs -->
<section class='informative' id='security'>
@@ -2232,6 +2109,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-17 - First attempt at correcting section ordering and anchors (SS)</li>
<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>