Added base-specs reference from intro
authorsspeiche
Wed, 22 Jan 2014 15:03:34 -0500
changeset 436 130a8b8a4583
parent 435 e9efbc3a3ba8
child 437 631936d65086
Added base-specs reference from intro
ldp.html
--- a/ldp.html	Wed Jan 22 12:09:38 2014 -0500
+++ b/ldp.html	Wed Jan 22 15:03:34 2014 -0500
@@ -251,6 +251,7 @@
 	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
 	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
 	implementations will support.</p>
+	<p>For context and background related to some standards, it could be useful to read <a href="#base-specs" class="sectionRef"></a>.</p>
 </section>
 	
 <section id="terms">
@@ -443,10 +444,7 @@
 <a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
 LDP does not constrain its behavior when serving other HTTP resources.
 </p>
-
-
 </div>
-
 </section>
 
 <section id="ldpclient">
@@ -1806,7 +1804,121 @@
 	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
 </section> <!-- h2 -->
 
-</section> <!-- h1 -->
+</section> <!-- h1 LDPC -->
+
+
+<section id="base-specs" class="informative">
+<h1>Notable information from normative references</h1>
+<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.
+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>
+
+<section id="specs-webarch" class="informative">
+<h2>Architecture of the World Wide Web</h2>
+Reference: [[!WEBARCH]]
+
+	<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.
+	</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.
+	</h2></section>
+
+</section> 
+
+<section id="specs-http" class="informative">
+<h2>HTTP 1.1</h2>
+Reference: [[!HTTP11]]
+
+	<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.
+	</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.
+	</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.
+	</h2></section>	
+	
+	<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.
+	</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]].
+	</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]].
+	</h2></section>
+
+</section> 
+
+<section id="specs-rdf" class="informative">
+<h2>RDF</h2>
+Reference: [[RDF-CONCEPTS]]
+
+	<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.
+	</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
+		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">Container
+		Member Information</a> for additional details.
+	</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.
+	</h2></section>
+
+</section> 
+
+<section id="specs-paging" class="informative">
+<h2>Feed paging and archiving</h2>
+Reference: [[RFC5005]]
+
+	<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]].
+	</h2></section>
+
+</section> 
+
+</section> <!-- Base specs -->
 
 <section>
 <h1>HTTP Header Definitions</h1>
@@ -1850,7 +1962,7 @@
 		resource identified by the <code>Request-URI</code>.
 	</h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
 	
-	<section id="header-accept-post-iana" ><h2 class="normal">IANA Registration Template</h2>
+	<section id="header-accept-post-iana"><h2 class="normal">IANA Registration Template</h2>
 	<div>
 	<blockquote>
 	<p>
@@ -1949,127 +2061,7 @@
 </section>
 </section> <!-- status code defns -->
     
-<section id="base-specs" class="informative">
-<h1>Notable information from normative references</h1>
-
-<div class="ldp-issue-open">
-<p>
-Given that it's from base specs =&gt; 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.
-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></div>
-
-<section id="specs-webarch" class="informative">
-<h1>Architecture of the World Wide Web</h1>
-Reference: [[!WEBARCH]]
-
-	<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.
-	</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.
-	</h2></section>
-
-</section> 
-
-<section id="specs-http" class="informative">
-<h1>HTTP 1.1</h1>
-Reference: [[!HTTP11]]
 
-	<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.
-	</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.
-	</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.
-	</h2></section>	
-	
-	<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.
-	</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]].
-	</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]].
-	</h2></section>
-
-</section> 
-
-<section id="specs-rdf" class="informative">
-<h1>RDF</h1>
-Reference: [[RDF-CONCEPTS]]
-
-	<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.
-	</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
-		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">Container
-		Member Information</a> for additional details.
-	</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.
-	</h2></section>
-
-</section> 
-
-<section id="specs-paging" class="informative">
-<h1>Feed paging and archiving</h1>
-Reference: [[RFC5005]]
-
-	<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]].
-	</h2></section>
-
-</section> 
-
-</section> <!-- Base specs -->
 
 <section class='informative' id='security'>
 <h1>Security Considerations</h1>
@@ -2109,6 +2101,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-21 - Put reference to <a href="#base-specs">base-specs</a> into intro section (SS)</li>
 	<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>