--- a/ldp.html	Mon Oct 28 12:25:16 2013 +0000
+++ b/ldp.html	Mon Oct 28 12:51:25 2013 -0400
@@ -558,7 +558,7 @@
 	<div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
 		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>)
+		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
 		in all responses to requests made 
 		to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
 		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
@@ -581,7 +581,7 @@
 	</div>
 	<div id="ldpr-4_2_13" class="rule">4.2.13 <a title="LDP server">LDP servers</a> MUST 
 		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
-		create or update LDPRs, by adding a Link header with <code>rel="describedby"</code> 
+		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
 		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
 		those constraints.  For example, a server that refuses resource creation 
 		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
@@ -815,7 +815,7 @@
 		Alternatively, a server could recognize that a resource that has been
 		requested is too big to return in a single message.</p>
 	<p>
-		To address this problem, resource should support a technique called Paging.  Paging can be achieved with a
+		To address this problem, resources should support a technique called Paging.  Paging can be achieved with a
 		simple pattern. For each resource, <code>&lt;resourceURL&gt;</code>, we define a new
 		'first page' resource.  In this example, its URL will be <code>&lt;resourceURL&gt;?firstPage</code>,
 		but servers are free to construct the URL as they see fit.
@@ -836,7 +836,7 @@
 		To find out if the resource supports paging, and if it does the URL of the first page, 
 		the client makes a <code>OPTIONS</code> or <code>HEAD</code> request
 		to <code>http://example.org/customer-relations</code>, and in the response looks for a HTTP <code>Link</code>
-		header with <code>rel="first"</code>; the target URI in the header is the URL
+		header with <code>rel='first'</code>; the target URI in the header is the URL
 		of the first page resource.
 		The client then 
 		requests the first page as <code>http://example.org/customer-relations?firstPage</code>, and
@@ -846,7 +846,7 @@
 <pre class="example"># The following is the representation of
 #    http://example.org/customer-relations?firstPage
 #    Requests on the ?firstPage URI will result in responses that include the following HTTP header
-#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel="next"
+#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
 #    This Link header is how clients discover the URI of the next page in sequence.
 @prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
 @prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@@ -874,7 +874,7 @@
 
 	<p>
 		The server determines the size of the pages using application specific methods not defined
-		within this specificiation. The value of the page URI is also
+		within this specificiation. The next page link's target URI is also
 		defined by the server and not this specification.
 	</p>
 	<p>
@@ -907,7 +907,7 @@
    foaf:name "Alfred E. Smith".</pre>
 	<p>
 		In this example, there are only two customers provided in the
-		final page.  To indicate this is the last page, the server omits the <code>Link rel="next"</code> 
+		final page.  To indicate this is the last page, the server omits the <code>Link rel='next'</code> 
 		header in its response.
 	</p>
 </section>
@@ -927,7 +927,7 @@
 		This is the mechanism by which clients can discover the URL of the first page.  
 		For example, if there is a LDPR with URL <code>&lt;resourceURL&gt;</code> that supports paging and whose
 		first page URL is <code>&lt;resourceURL&gt;?theFirstPage</code>, then the corresponding link header
-		would be <code>Link: &lt;?theFirstPage&gt;;rel="first"</code>.
+		would be <code>Link: &lt;?theFirstPage&gt;;rel='first'</code>.
 		If no such <code>Link</code> header is present, 
 		then clients have no LDP-defined way to discover that the resource supports paging or the
 		URI of the first page.
@@ -1807,7 +1807,7 @@
 		For example, if there is a LDPC with URL <code>&lt;containerURL&gt;</code> whose corresponding
 		non-member resource 
 		URL is <code>&lt;containerURL&gt;?nonMemberProperties</code>, then the corresponding link header
-		would be <code>Link: &lt;?nonMemberProperties&gt;;rel="http://www.w3.org/ns/ldp#nonMemberResource"</code>
+		would be <code>Link: &lt;?nonMemberProperties&gt;;rel='http://www.w3.org/ns/ldp#nonMemberResource'</code>
 	</div>
 	
 	<div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose