--- 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 => 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>