Fixed vanishing section ref problem
authorsspeiche
Tue, 17 Sep 2013 14:10:41 -0400
changeset 333 3c2aaaea1f73
parent 332 120e056d8425
child 334 8e9ad2d0e512
Fixed vanishing section ref problem
ldp.html
--- 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 &mdash;
 	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>