ldp.html
changeset 190 fca354408433
parent 189 ccdf7eb55d7a
child 191 ab6b24fcb2b6
--- a/ldp.html	Thu Jul 11 14:26:05 2013 -0400
+++ b/ldp.html	Thu Jul 11 15:16:58 2013 -0400
@@ -380,18 +380,18 @@
 		set explicitly.  This makes the representations much more useful to
 		client applications that don’t support inferencing.
 	</div>
-	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPR servers MAY support standard representations beyond those
+	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPR servers 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>
 		
-	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MAY be created, updated and deleted using methods not defined in
+	<div id="ldpr-4_1_8" class="rule">4.1.8 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_1_10" class="rule">4.1.10 LDPR server responses MUST use entity tags (either weak or strong 
+	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR server responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
 	
@@ -400,7 +400,7 @@
 	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
 	</div>
 
-	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR
+	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
 		common for LDPR servers to put restrictions on representations – for
@@ -417,7 +417,7 @@
 	How can a client determine that it is in communication with an LDP server?
 	</div>
 
-	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR servers
+	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers
 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
 		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
 		a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
@@ -436,7 +436,7 @@
 	inferencing levels
 	</div>
 
-	<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR servers
+	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR servers
 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
 		of content defined by LDP.  Other specifications built on top of LDP MAY require clients
 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
@@ -524,7 +524,7 @@
 	</div>
 	<div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers 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_1_11">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_10">enable simple creation and modification</a> of LPDRs.
 	</div>		
 </section>
 		
@@ -574,7 +574,7 @@
 
 	<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers 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_1_11">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_10">enable simple creation and modification</a> of LPDRs.
 	</div>
 
 	<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH.
@@ -739,7 +739,7 @@
 <h3 id="ldpr-PagingGET">HTTP GET</h3>
 <p>In addition to the requirements set forth in section (HTTP GET), LDPR Servers that support paging must also follow the requirements in this section</p>
 
-	<div id="ldpr-5_3_4" class="rule">5.3.4 LDPR servers SHOULD allow clients to retrieve large LDPRs in
+	<div id="ldpr-pagingGET-1" class="rule">4.9.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
 		pages. In responses to <code>GET</code> requests with an LDPR as the Request-URI, 
 		LDPR servers that support paging SHOULD provide an HTTP <code>Link</code>
 		header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]]. 
@@ -751,29 +751,29 @@
 		The representation for any page, including the first, will include
 		the URL for the next page. See section <a href="#ldpr-paging">4.7 Paging</a> for additional details.
 	</div>
-	<div id="ldpc-5_3_5" class="rule">5.3.5 LDPR servers MAY split the response representation of any LDPR. 
+	<div id="ldpr-pagingGET-2" class="rule">4.9.2.2 LDPR servers MAY split the response representation of any LDPR. 
 		This is known as
 		server-initiated paging. See section  <a href="#ldpr-paging">4.7 Paging</a> for
 		additional details.
 	</div>
-	<div id="ldpc-5_3_5_1" class="rule">5.3.5.1 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
+	<div id="ldpr-pagingGET-3" class="rule">4.9.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
 		by redirecting the client to the first page resource using a <code>303 See
 		Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
 	</div>
-	<div id="ldpc-5_3_6" class="rule">5.3.6 LDPR servers that support paging MUST include in the page
+	<div id="ldpr-pagingGET-4" class="rule">4.9.2.4 LDPR servers that support paging MUST include in the page
 		representation a representation for the LDPR, such that:
 	</div>
-	<div id="ldpc-5_3_6_1" class="rule">5.3.6.1 The page resource representation SHOULD have one triple to indicate its
+	<div id="ldpr-pagingGET-5" class="rule">4.9.2.5 The page resource representation SHOULD have one triple to indicate its
 		type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
 		It also SHOULD have 1 triple to indicate the resource it is paging,
 		whose  subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
 		and object is the URL of the LDPC.
 	</div>
-	<div id="ldpc-5_3_6_2" class="rule">5.3.6.2 The page resource representation MUST have one triple with the subject
+	<div id="ldpr-pagingGET-6" class="rule">4.9.2.6 The page resource representation MUST have one triple with the subject
 		of the page, predicate of <code>ldp:nextPage</code> and
 		object being the URL for the subsequent page.
 	</div>
-	<div id="ldpc-5_3_6_3" class="rule">5.3.6.3 The last page resource representation MUST have one triple with the subject of the 
+	<div id="ldpr-pagingGET-7" class="rule">4.9.2.7 The last page resource representation MUST have one triple with the subject of the 
 	    last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
 	</div>
 </section>
@@ -1398,7 +1398,7 @@
 		<a href="#ldpc-5_2_3">5.2.3</a>.
 	</div>
 	
-	<div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
+	<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
 		order.  If the server does so, it MUST be specify the order using a triple 
 		whose subject is the page URI, 
 		whose predicate is <code>ldp:containerSortCriteria</code>, 
@@ -1416,7 +1416,7 @@
 		an example.
 	</div>
 	
-	<div id="ldpc-5_3_8" class="rule">5.3.8 LDPC page representations 
+	<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations 
 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
 		in every <code>ldp:containerSortCriterion</code> list entry, 
 		a triple
@@ -1430,7 +1430,7 @@
 		assigns no meaning to them and interoperability will be limited.
 	</div>
 	
-	<div id="ldpc-5_3_9" class="rule">5.3.9 LDPC page representations 
+	<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC page representations 
 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
 		in every <code>ldp:containerSortCriterion</code> list entry, 
 		a triple
@@ -1449,7 +1449,7 @@
 	referring readers to SPARQL 1.1.  Which normative reference do we want?
 	</div>
 
-	<div id="ldpc-5_3_10" class="rule">5.3.10 LDPC page representations 
+	<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC page representations 
 		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
 		in any <code>ldp:containerSortCriterion</code> list entry,
 		a triple
@@ -1532,7 +1532,7 @@
 	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
 		This is a consequence of the requirement to 
-		<a href="#ldpr-4_1_11">enable simple creation and modification</a> of LPDRs.
+		<a href="#ldpr-4_1_10">enable simple creation and modification</a> of LPDRs.
 	</div>
 	<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers MAY allow clients to suggest the URI for a resource
 		created through POST, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
@@ -1850,8 +1850,8 @@
 		resource identified by the <code>Request-URI</code>.
 	</div>
 	
-<section>
-<h3 id="header-accept-post-iana">IANA Registration Template</h3>
+	<div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
+	<div>
 	<blockquote>
 	<p>
 	The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
@@ -1869,7 +1869,7 @@
 	Specification document:  this specification
 	</p>
 	</blockquote>
-</section>
+	</div>
 
 </section>
 </section> <!-- Header defns -->
@@ -1899,6 +1899,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-07-11 - Section number fixup: 4.1.8-13-&gt;7-12, 4.9.2.* fixup, 5.3.7-10-&gt;>2-5 (SS)</li>
 	<li>2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)</li>
 	<li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
 	<li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
@@ -2018,8 +2019,6 @@
 	</li>
 	<li>using "sectionRef" instead of hardwiring
 	</li>
-	<li>using respec section labeling consistently
-	</li>
 	<li>update ldpc samples with all required props
 	</li>
 </ul>