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