ldp.html
changeset 386 b7c514f96add
parent 385 9686ab858357
child 387 85cebac44f86
--- 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>