--- a/ldp.html Fri Oct 25 14:54:56 2013 +0100
+++ b/ldp.html Fri Oct 25 14:55:16 2013 +0100
@@ -52,7 +52,7 @@
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
- publishDate: "2013-08-19",
+ publishDate: "",
// if the specification's copyright date is a range of years, specify
// the start date here:
@@ -110,6 +110,28 @@
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
+ localBiblio: {
+ "HTTPBIS-SEMANTICS": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+ , href: "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
+ , authors: [
+ "R. Fielding"
+ , "J. Reschke"
+ ]
+ , status: "In Last Call"
+ , publisher: "IETF"
+ },
+ "RFC2817": {
+ title: "Upgrading to TLS Within HTTP/1.1"
+ , href: "http://tools.ietf.org/html/rfc2817"
+ , authors: [
+ "R. Khare"
+ , "S. Lawrence"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ }
+ },
};
</script>
<style type="text/css">
@@ -481,16 +503,20 @@
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>
@@ -542,11 +568,13 @@
<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>
+ <!-- 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,
<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
</div>
@@ -572,7 +600,8 @@
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, <a title="LDP server">LDP servers</a> MUST
+ <div id="ldpr-4_5_1" class="rule">4.5.1 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.
<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code>
@@ -583,6 +612,23 @@
<code>PATCH</code>, not HTTP <code>PUT</code>.
</div>
+ <div id="ldpr-4_5_1_1" class="rule">4.5.1.1
+ 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
+ respond with a 4xx range status code (typically
+ 409 Conflict).
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which triples could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP.
+ </div>
+ <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>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
@@ -599,11 +645,15 @@
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 <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, <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 id="ldpr-4_5_4" class="rule">4.5.4
+ If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
+ chooses not to persist, e.g. unknown content,
+ <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+ [[HTTP11]].
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which triples could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP.
</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
@@ -627,18 +677,22 @@
<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">
@@ -655,10 +709,12 @@
<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>
+ <!-- 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_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.
@@ -717,8 +773,9 @@
- same subject, predicate and object.
</p>
<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 by returning the first page resource –
+ using a <a href="#status-code-related-content"><code>209 Related Content</code></a> response
+ with a <code>Location</code> header containing the URL for the page
resource. Alternatively, clients may introspect the resource for a paged representation
and use it preferentially when available.</p>
<p>
@@ -825,9 +882,10 @@
See <a href="#ldpr-Paging" class="sectionRef"></a> for
additional details.
</div>
- <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 id="ldpr-pagingGET-3" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a>
+ that initiate paging MUST respond to requests for a LDPR
+ by returning the first page resource using a <code>209 Related Content</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 <a title="LDP server">LDP servers</a> that support paging MUST include a representation for the page resource.
</div>
@@ -1228,9 +1286,11 @@
<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>
SHOULD use the <code>rdfs:member</code> predicate
If there is no obvious predicate from an application vocabulary to use.
@@ -1276,6 +1336,7 @@
(<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
@@ -1284,13 +1345,15 @@
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 <code>rdf:type</code>
- of <code>ldp:Container</code>, but it MAY have additional
- <code>rdf:type</code>s.
+ -->
+ <div id="ldpc-5_2_7" class="rule">5.2.7 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>,
<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
@@ -1298,6 +1361,7 @@
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 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 in the membership triple, LDPCs MUST contain one triple whose
@@ -1418,7 +1482,7 @@
resulting order is as defined by SPARQL SELECT’s ORDER BY clause
[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the
specified collation.
- The <code>ldp:containerSortCollation</code> triple SHOULD be omitted for comparisons
+ 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>
</section>
@@ -1456,8 +1520,11 @@
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. When the header is absent,
+ 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
URI for the subject of triples in the LDPR representation in the
@@ -1562,12 +1629,16 @@
(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 the LDPC server successfully completes the <code>DELETE</code> request on a LDPC, it MUST remove any
- membership triples associated with the LDPC as indicated by the canonical <code>Request-URI</code>. The LDPC server MAY perform additional removal
- of member resources.
+ <div id="ldpc-5_6_2" class="rule">5.6.2 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>
+ <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.
- </div>
+ </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
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.
@@ -1701,6 +1772,79 @@
</section>
</section> <!-- Header defns -->
+<section>
+<h1>HTTP Status Code Definitions</h1>
+
+<section id="status-code-related-content">
+<h2>209 Related Content</h2>
+
+ <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+ <ul>
+ <li>The addition of <a>209 Related Content</a> in this specification is pending
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
+ that would fully include it, patterned after the codes defined by [[RFC6585]]. Once LDP is in
+ Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
+ working with the W3C Director.</li>
+ </ul>
+ </div>
+
+ <p>The <code>209 Related Content</code> status code indicates that the origin server
+ is supplying the representation of a different resource than the target resource,
+ and the origin server believes that the supplied representation
+ is likely to satisfy the user agent's original request.
+ The resource whose representation is supplied is descriptive of the target resource, in
+ the same way that the <code>Location</code> header in a <code>303 See Other</code>
+ response is descriptive of the target resource.
+ </p>
+ <p><code>209 Related Content</code> is intended to be used in situations where
+ <code>303 See Other</code> could have been used and would most likely result in a
+ user agent retrieving the other resource, but saves the user agent from
+ the latency penalty of having to perform a separate retrieval request.
+ </p>
+
+ <p> LDP uses <code>209 Related Content</code> to provide clients with the
+ <a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
+ other common situations. Linked Data clients could benefit by avoiding the latency
+ of additional requests when the target resource is a concept resource (one without any
+ representation capable of transmission over HTTP), and general HTTP clients would
+ benefit in many of the more general cases where <code>303 See Other</code> responses
+ are currently used.
+ </p>
+
+ <div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a <code>Location</code> header with the same
+ <code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
+ </div>
+
+ <div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a representation of the resource identified
+ by the response's <code>Location</code> header.
+ </div>
+
+ <div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
+ <div>
+ <blockquote>
+ <p>
+ The <code>209 Related Content</code> must be added to the permanent status code registry
+ maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
+ (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+ </p>
+ <p>
+ Value: 209
+ </p>
+ <p>
+ Description: Related Content
+ </p>
+ <p>
+ Reference: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> <!-- status code defns -->
+
<section id="ldpclient">
<h1>Linked Data Platform Clients</h1>
<div class="ldp-issue-open">
@@ -1735,16 +1879,15 @@
<section id="base-specs" class="informative">
<h1>Notable information from normative references</h1>
+
<div class="ldp-issue-open">
-
<p>
-AT THIS POINT ALL TEXT HAS BEEN COPIED HERE, NOT MOVED.
-DEPENDING UPON HOW THE WG ALTERS THE PROPOSAL BASED ON FEEDBACK, IT MIGHT CHANGE.
-THE 2119 LANGUAGE NEEDS TO BE REMOVED TOO.
Given that it's from base specs => important to understand, should be moved up before
most of the normative sections IMO - renumbering hit again.
</p>
+</div>
+<div class="ldp-issue-pending">
<p>
While readers, and especially implementers, of LDP are assumed to understand the information in its normative
references, the working group has found that certain points are particularly important to understand.
@@ -1755,15 +1898,15 @@
<section id="specs-webarch" class="informative">
<h1>Architecture of the World Wide Web</h1>
-Reference: [[WEBARCH]]
+Reference: [[!WEBARCH]]
- <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 id="ldp-webarch-nonexcl-membership" class="rule">9.1.1 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="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs,
+ <div id="ldp-webarch-uri-reuse" class="rule">9.1.2 <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]].
+ 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>
@@ -1772,45 +1915,42 @@
<section id="specs-http" class="informative">
<h1>HTTP 1.1</h1>
-Reference: [[HTTP11]]
+Reference: [[!HTTP11]]
- <div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
+ <div id="ldp-http-other-representations" class="rule">9.2.1 <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.
+ 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="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
+ <div id="ldp-http-other-methods" class="rule">9.2.2 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
+ UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
normative requirements.
</div>
- <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).
- </div>
- <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 id="ldp-http-delete-uri-reuse" class="rule">9.2.3 <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>
- <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
+ <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
+ 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. It is also acceptable and common for <a title="LDP server">LDP servers</a> to
- not do this – behavior is server application specific.
+ 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="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 id="ldp-http-patch-allowed" class="rule">9.2.5 <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="ldpc-5_4_2" class="rule">5.4.2 ... An LDPC MAY also contain resources that were
- added through other means ... stays normative, sept 25 email
- </div>
- <div id="ldpc-5_4_6" class="rule">5.4.6 ... 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_10" class="rule">5.4.10 ... stays normative, sept 25 email
+ <div id="ldp-http-content-sniffing" class="rule">9.2.6
+ 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>
</section>
@@ -1819,18 +1959,21 @@
<h1>RDF</h1>
Reference: [[RDF-CONCEPTS]]
- <div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
+ <div id="ldp-rdfconcepts-extra-triples-any" class="rule">9.3.1 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
+ 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
- representations). This allows a LDPC server to provide clients with
+ representations). This allows a <a>LDP server</a> 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
+ on each member individually. See <a href="#ldpc-member_data">Container
Member Information</a> for additional details.
</div>
- <div id="ldpc-5_2_7" class="rule">5.2.7 , but it [The representation of a LDPC] MAY have additional
- <code>rdf:type</code>s.
- </div>
- <div id="ldpc-5_3_1" class="rule">5.3.1 ... stays normative, sept 25 email
+ <div id="ldp-rdfconcepts-extra-triples-types" class="rule">9.3.3 The state of an LDPR can have more than one
+ triple with a <code>rdf:type</code> predicate.
</div>
</section>
@@ -1864,6 +2007,13 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> -->
<ul>
+ <li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -> SHOULD (JA)</li>
+ <li>2013-10-21 - Mock up status code 209 Related Content (JA)</li>
<li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
<li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
<li>2013-10-01 - Revising introduction (JA)</li>