--- a/ldp.html Mon Sep 16 11:10:19 2013 -0500
+++ b/ldp.html Tue Sep 17 14:10:41 2013 -0400
@@ -182,8 +182,8 @@
data model.
</section>
-<section class="informative">
-<h1 id="intro">Introduction</h1>
+<section class="informative" id="intro">
+<h1>Introduction</h1>
<p>This document describes the use
of HTTP for accessing, updating, creating and deleting resources from
servers that expose their resources as Linked Data. It provides clarifications
@@ -214,8 +214,8 @@
implementations will support.</p>
</section>
-<section>
-<h1 id="terms">Terminology</h1>
+<section id="terms">
+<h1>Terminology</h1>
<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
</p>
@@ -298,8 +298,8 @@
</dl>
-<section>
-<h2 id="conventions">Conventions Used in This Document</h2>
+<section id="conventions">
+<h2>Conventions Used in This Document</h2>
<p>Sample resource representations are provided in <code>text/turtle</code>
format [[TURTLE]].</p>
@@ -338,11 +338,11 @@
</section>
-<section>
-<h1 id="ldpr">Linked Data Platform Resources</h1>
+<section id="ldpr">
+<h1>Linked Data Platform Resources</h1>
-<section class="informative">
-<h2 id="ldpr-informative">Informative</h2>
+<section class="informative" id="ldpr-informative">
+<h2>Informative</h2>
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
that conform to the simple patterns and conventions in this section.
HTTP requests to access, modify, create or delete LDPRs are accepted
@@ -380,8 +380,8 @@
</section>
-<section>
-<h2 id="ldpr-general">General</h2>
+<section id="ldpr-general">
+<h2>General</h2>
<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an RDF representation for LDPRs.
@@ -455,8 +455,8 @@
</section>
-<section>
-<h2 id="ldpr-HTTP_GET">HTTP GET</h2>
+<section id="ldpr-HTTP_GET">
+<h2>HTTP GET</h2>
<div id="ldpr-4_3_1" class="rule">4.3.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
</div>
<div id="ldpr-4_3_2" class="rule">4.3.2 LDPR servers MUST support the HTTP response headers defined in
@@ -479,8 +479,8 @@
</div>
</section>
-<section>
-<h2 id="ldpr-HTTP_POST">HTTP POST</h2>
+<section id="ldpr-HTTP_POST">
+<h2>HTTP POST</h2>
<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs
even when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
@@ -489,8 +489,8 @@
sections for more details.</p>
</section>
-<section>
-<h2 id="ldpr-HTTP_PUT">HTTP PUT</h2>
+<section id="ldpr-HTTP_PUT">
+<h2>HTTP PUT</h2>
<p>This specification imposes the following new requirements on HTTP <code>PUT</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>
@@ -542,8 +542,8 @@
</div>
</section>
-<section>
-<h2 id="ldpr-HTTP_DELETE">HTTP DELETE</h2>
+<section id="ldpr-HTTP_DELETE">
+<h2>HTTP DELETE</h2>
<p>This specification imposes the following new requirements on HTTP <code>DELETE</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>
@@ -564,17 +564,17 @@
</div>
</section>
-<section>
-<h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
+<section id="ldpr-HTTP_HEAD">
+<h2>HTTP HEAD</h2>
<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses.
- Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a>
- and <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.</p>
+ Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a>
+ and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
</section>
-<section>
-<h2 id="ldpr-HTTP_PATCH">HTTP PATCH</h2>
+<section id="ldpr-HTTP_PATCH">
+<h2>HTTP PATCH</h2>
<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>
@@ -596,8 +596,8 @@
</section>
-<section>
-<h2 id="ldpr-HTTP_OPTIONS">HTTP OPTIONS</h2>
+<section id="ldpr-HTTP_OPTIONS">
+<h2>HTTP OPTIONS</h2>
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs
beyond those in [[!HTTP11]]. Other sections of this specification, for example
<a href="#ldpr-HTTP_PATCH">PATCH</a>,
@@ -614,11 +614,11 @@
</section>
-<section>
-<h2 id="ldpr-Paging">Paging</h2>
+<section id="ldpr-Paging">
+<h2>Paging</h2>
-<section class="informative">
-<h3 id="ldpr-PagingIntro">Introduction</h3>
+<section class="informative" id="ldpr-PagingIntro">
+<h3>Introduction</h3>
<p>It sometimes happens that a
resource is too large to reasonably transmit its representation in a
single HTTP response. This will be especially true if the resource
@@ -728,8 +728,8 @@
</p>
</section>
-<section>
-<h3 id="ldpr-PagingGET">HTTP GET</h3>
+<section id="ldpr-PagingGET">
+<h3>HTTP GET</h3>
<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, LDPR servers that support paging must also follow the requirements in this section</p>
<div id="ldpr-pagingGET-1" class="rule">4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
@@ -777,8 +777,8 @@
</div>
</section>
-<section>
-<h3 id="ldpr-paging-HTTP_OPTIONS">HTTP OPTIONS</h3>
+<section id="ldpr-paging-HTTP_OPTIONS">
+<h3>HTTP OPTIONS</h3>
<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers MUST indicate their support for client-initiated paging by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
@@ -788,8 +788,8 @@
</section>
-<section>
-<h2 id="ldpr-inlining">Resource Inlining: Representing Multiple Resources in a Response</h2>
+<section id="ldpr-inlining">
+<h2>Resource Inlining: Representing Multiple Resources in a Response</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>
@@ -801,8 +801,8 @@
in <a href="#sotd">Status of This Document</a>.</p>
</div>
-<section class="informative">
-<h3 id="ldpr-InliningIntro">Introduction</h3>
+<section class="informative" id="ldpr-InliningIntro">
+<h3>Introduction</h3>
<p>Servers whose resources are relatively granular may wish to optimistically provide more information
in a response than what the client actually requested, in order to reduce the average number of client
application HTTP flows. LDP provides some basic building blocks to enable
@@ -827,8 +827,8 @@
</p>
</section> <!-- h3 -->
-<section class="informative">
-<h3 id="ldpr-InliningWarnings">Use with Care</h3>
+<section class="informative" id="ldpr-InliningWarnings">
+<h3>Use with Care</h3>
<p>The building blocks LDP provides can only be safely used if certain assumptions hold.
Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case —
so if you care about any of the following in a given application, your server should avoid returning
@@ -853,8 +853,8 @@
</ul>
</section> <!-- h3 -->
-<section>
-<h3 id="ldpr-InliningGET">HTTP GET</h3>
+<section id="ldpr-InliningGET">
+<h3>HTTP GET</h3>
<p>In addition to the requirements set forth in other sections,
LDPR servers that support <a>resource inlining</a>
must also follow the requirements in this section.</p>
@@ -903,11 +903,11 @@
</section> <!-- h1 -->
-<section>
-<h1 id="ldpc">Linked Data Platform Containers</h1>
+<section id="ldpc">
+<h1>Linked Data Platform Containers</h1>
-<section class="informative">
-<h2 id="ldpc-informative">Informative</h2>
+<section class="informative" id="ldpc-informative">
+<h2>Informative</h2>
<p>Many HTTP applications and sites have organizing
concepts that partition the overall space of resources into smaller
containers. Blog posts are grouped into blogs, wiki pages are grouped
@@ -1253,8 +1253,8 @@
</p>
</section>
-<section>
-<h2 id="ldpc-general">General</h2>
+<section id="ldpc-general">
+<h2>General</h2>
<p>The Linked Data Platform does not define how clients
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
@@ -1367,8 +1367,8 @@
</section>
-<section>
-<h2 id="ldpc-HTTP_GET">HTTP GET</h2>
+<section id="ldpc-HTTP_GET">
+<h2>HTTP GET</h2>
<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of triples with a
consistent subject and predicate whose objects indicate members of
@@ -1443,8 +1443,8 @@
</div>
</section>
-<section>
-<h2 id="ldpc-HTTP_POST">HTTP POST</h2>
+<section id="ldpc-HTTP_POST">
+<h2>HTTP POST</h2>
<p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
@@ -1540,8 +1540,8 @@
</section>
-<section>
-<h2 id="ldpc-HTTP_PUT">HTTP PUT</h2>
+<section id="ldpc-HTTP_PUT">
+<h2>HTTP PUT</h2>
<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
@@ -1571,8 +1571,8 @@
</section>
-<section>
-<h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
+<section id="ldpc-HTTP_DELETE">
+<h2>HTTP DELETE</h2>
<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
@@ -1600,8 +1600,8 @@
</section>
-<section>
-<h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
+<section id="ldpc-HTTP_HEAD">
+<h2>HTTP HEAD</h2>
<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPC servers must also include HTTP headers
on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
@@ -1609,8 +1609,8 @@
<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
</section>
-<section>
-<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
+<section id="ldpc-HTTP_PATCH">
+<h2>HTTP PATCH</h2>
<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
@@ -1620,8 +1620,8 @@
</div>
</section>
-<section>
-<h2 id="ldpc-HTTP_OPTIONS">HTTP OPTIONS</h2>
+<section id="ldpc-HTTP_OPTIONS">
+<h2>HTTP OPTIONS</h2>
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
</p>
@@ -1653,8 +1653,8 @@
<code>meta</code> [[!RFC5988]].</div>
</section>
-<section>
-<h2 id="ldpc-inlining">Member Inlining: Returning All of a Container Page's Members in a Response</h2>
+<section id="ldpc-inlining">
+<h2>Member Inlining: Returning All of a Container Page's Members in a Response</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>
@@ -1666,8 +1666,8 @@
in <a href="#sotd">Status of This Document</a>.</p>
</div>
-<section class="informative">
-<h3 id="ldpc-InliningIntro">Introduction</h3>
+<section class="informative" id="ldpc-InliningIntro">
+<h3>Introduction</h3>
<p>One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of
<i>m</i> members from having to perform <i>m+1</i> HTTP requests (or <i>m+p</i>, if the container
is paged into <i>p</i> pages). The desire is to allow the server to reduce the number of HTTP
@@ -1692,8 +1692,8 @@
</p>
</section> <!-- h3 -->
-<section>
-<h3 id="ldpc-InliningGET">HTTP GET</h3>
+<section id="ldpc-InliningGET">
+<h3>HTTP GET</h3>
<p>In addition to the requirements set forth in other sections,
LDPC servers that support <a>member inlining</a>,
and LDP clients aware of the same facility,
@@ -1734,8 +1734,8 @@
<section>
<h1>HTTP Header Definitions</h1>
-<section>
-<h2 id="header-accept-post">The Accept-Post Response Header</h2>
+<section id="header-accept-post">
+<h2>The Accept-Post Response Header</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>
@@ -1820,6 +1820,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> -->
<ul>
+ <li>2013-09-17 - Fixed vanishing section ref problem (SS)</li>
<li>2013-08-19 - Basic preparation for edits unto LC draft (SS)</li>
</ul>