Fixed various section marking issues with informative
authorsspeiche
Thu, 11 Jul 2013 16:08:31 -0400
changeset 191 ab6b24fcb2b6
parent 190 fca354408433
child 192 221002315344
Fixed various section marking issues with informative
ldp.html
--- a/ldp.html	Thu Jul 11 15:16:58 2013 -0400
+++ b/ldp.html	Thu Jul 11 16:08:31 2013 -0400
@@ -619,11 +619,9 @@
 
 <section>
 <h2 id="ldpr-Paging">Paging</h2>
-<em>Suggest creating a separate "last" section for LDPRs to not clutter everything else</em>
 
-<section>
+<section class="informative">
 <h3 id="ldpr-PagingIntro">Introduction</h3>
-	<em>This section is non-normative</em>
 	<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
@@ -807,10 +805,8 @@
 		in <a href="#sotd">Status of This Document</a>.</p>
 	</div>
 
-<section>
+<section class="informative">
 <h3 id="ldpr-InliningIntro">Introduction</h3>
-	<em>This section is non-normative.</em>
-	
 	<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
@@ -835,10 +831,8 @@
 	</p>
 </section> <!-- h3 -->
 
-<section>
+<section class="informative">
 <h3 id="ldpr-InliningWarnings">Use with Care</h3>
-	<em>This section is non-normative.</em>
-	
 	<div class="ldp-issue-pending">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
 	Action 87: Add an informative section on the possible dangers of inlining resources
@@ -1081,8 +1075,7 @@
 			triples whose subject is the LDPC resource itself.
 	</p>
 	
-	<div id="ldpc-member_data" class="rule">5.1.1 Container Member Information</div>
-	<em>This section is non-normative</em>
+	<div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
 	<p>In many – perhaps most – applications
 		involving containers, it is desirable for the client to be able to
 		get information about each container member without having to do a
@@ -1660,19 +1653,15 @@
 	created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server must also remove the associated LDPR it created.
 	</div>	
 	
-	
-
 </section>
 
 <section>
 <h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
-
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
 		HEAD responses include the same headers as GET responses. Also LDPR servers must also include HTTP headers
 		on response to OPTIONS, see <a href="#ldpr-4_6_2">4.6.2</a>.
 		Thus, implementers supporting HEAD should also carefully read the
 		<a href="#ldpc-HTTP_GET">GET section</a> and <a href="#ldpc-HTTP_OPTIONS">OPTIONS section</a>.</p>
-	
 </section>
 
 <section>
@@ -1732,10 +1721,8 @@
 		in <a href="#sotd">Status of This Document</a>.</p>
 	</div>
 
-<section>
+<section class="informative">
 <h3 id="ldpc-InliningIntro">Introduction</h3>
-	<em>This section is non-normative.</em>
-	
 	<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
@@ -1810,8 +1797,6 @@
 	</section>
 
 </section> <!-- h2 -->
-
-
 </section>
 
 <section>