--- a/ldp.html Tue Oct 22 13:08:45 2013 -0400
+++ b/ldp.html Tue Oct 22 14:50:32 2013 -0400
@@ -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>
@@ -627,18 +655,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 +687,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.
@@ -1229,9 +1263,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.
@@ -1277,6 +1313,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
@@ -1285,13 +1322,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
@@ -1299,6 +1338,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
@@ -1457,8 +1497,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
@@ -1758,7 +1801,7 @@
<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]]).
+ (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
</p>
<p>
Value: 209
@@ -1809,16 +1852,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.
@@ -1829,15 +1871,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>
@@ -1846,45 +1888,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>
@@ -1893,18 +1932,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>
@@ -1938,6 +1980,7 @@
<!-- <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-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>