ldp.html
changeset 192 221002315344
parent 191 ab6b24fcb2b6
child 194 b6d66196a02d
--- a/ldp.html	Thu Jul 11 16:08:31 2013 -0400
+++ b/ldp.html	Thu Jul 11 16:52:09 2013 -0400
@@ -256,12 +256,12 @@
 	
 	<dt><dfn>Resource inlining</dfn></dt>
 	<dd>
-		The practice of responding to a HTTP <code>GET</code> request made to a <code>request-URI</code> R<sub>0</sub> with
-		a representation that includes the state of R<sub>0</sub>, the <em>entire</em> state of resources accessed through
-		<em>other</em> <code>request-URI</code>(s) R<sub>1</sub>...R<sub>n</sub>, <em>and assertions</em> from the server 
+		The practice of responding to a HTTP GET request made to a request URI <var>R<sub>0</sub></var> with
+		a representation that includes the state of <var>R<sub>0</sub></var>, the <em>entire</em> state of resources accessed through
+		<em>other</em> request URI(s) <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var>, <em>and assertions</em> from the server 
 		identifying the additional resources whose
 		entire state has been provided.
-		R<sub>1</sub>...R<sub>n</sub> identify the inlined resource(s).
+		<var>R<sub>1</sub></var>...<var>R<sub>n</sub></var> identify the inlined resource(s).
 		See <a href="#ldpr-inlining" class="sectionRef"></a> for details.
 	<p></p></dd>
 	
@@ -355,7 +355,7 @@
 		
 	<div id="ldpr-4_1_1" class="rule">4.1.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
 	<div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs. 
-	The HTTP Request-URI of the LDPR is typically the subject of most triples in the response.
+	The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
 	</div>
 	<div id="ldpr-4_1_3" class="rule">4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
 		is common for LDPR servers to need to host binary or text resources
@@ -370,28 +370,22 @@
 		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
 		possible.
 	</div>
-	<div id="ldpr-4_1_5" class="rule"><del>4.1.5 LDPRs MUST use the predicate <code>rdf:type</code> to
-		represent the concept of type. The use of non-standard type
-		predicates, as well as <code>dcterms:type</code>, is
-		discouraged, as it is not recommended
-		by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]]. </del>
-	</div>
-	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR representations SHOULD have at least one <code>rdf:type</code>
+	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPR representations SHOULD have at least one <code>rdf:type</code>
 		set explicitly.  This makes the representations much more useful to
 		client applications that don’t support inferencing.
 	</div>
-	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPR servers MAY support standard representations beyond those
+	<div id="ldpr-4_1_6" class="rule">4.1.6 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_8" class="rule">4.1.8 LDPRs MAY be created, updated and deleted using methods not defined in
+	<div id="ldpr-4_1_7" class="rule">4.1.7 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_9" class="rule">4.1.9 LDPR server responses MUST use entity tags (either weak or strong 
+	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPR server responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
 	
@@ -400,7 +394,7 @@
 	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
 	</div>
 
-	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR
+	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
 		common for LDPR servers to put restrictions on representations – for
@@ -417,18 +411,18 @@
 	How can a client determine that it is in communication with an LDP server?
 	</div>
 
-	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers
+	<div id="ldpr-4_1_10" class="rule">4.1.10 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>)
 		in all responses to requests made 
-		to the resource's HTTP <code>request-URI</code>. This is notionally equivalent to the
-		presence of a <code>&lt; subject-URI, rdf:type , ldp:Resource &gt;</code> triple in the resource.
+		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.
 		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP spec in a way
 		that clients can introspect dynamically at run-time.  Conservative clients should note that 
 		a server can host a mixture of LDPRs and other resources, and therefore there is no implication
-		that LDP support advertised on one HTTP <code>request-URI</code> means that other 
-		resources on the same server are also LDPRs.  Each HTTP <code>request-URI</code> needs to be 
+		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
+		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
 		individually introspected by a conservative client, in the absence of outside information.
 	</div>
 <div class="ldp-issue-pending">
@@ -436,7 +430,7 @@
 	inferencing levels
 	</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 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
@@ -447,7 +441,7 @@
 
 <section>
 <h2 id="ldpr-HTTP_GET">HTTP GET</h2>
-	<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.
+	<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
 	</div>
 	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide a <code>text/turtle</code>
 		representation of the requested LDPR [[!TURTLE]].
@@ -468,20 +462,20 @@
 
 <section>
 <h2 id="ldpr-HTTP_POST">HTTP POST</h2>
-	<p>This specification adds no new requirements on HTTP POST for LDPRs 
+	<p>This specification adds no new requirements on HTTP <code>POST</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>
-	<p>Creation of LDPRs is done via HTTP POST to a LDPC, see the section <a href="#ldpc-HTTP_POST">HTTP POST</a>
+	<p>Creation of LDPRs is done via HTTP <code>POST</code> to a LDPC, see the section <a href="#ldpc-HTTP_POST">HTTP POST</a>
 	 in the LDPC parent section for more details.</p>
 </section>
 
 <section>
 <h2 id="ldpr-HTTP_PUT">HTTP PUT</h2>
-	<p>This specification imposes the following new requirements on HTTP PUT for LDPRs 
+	<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>
 		
-	<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers MUST
+	<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
 		replace the entire persistent state of the identified resource with
 		the entity representation in the body of the request. 
 		LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code> 
@@ -489,7 +483,7 @@
 		client control. Any LDPR servers that wish
 		to support a more sophisticated merge of data provided by the client
 		with existing state stored on the server for a resource MUST use HTTP
-		PATCH, not HTTP PUT.
+		<code>PATCH</code>, not HTTP <code>PUT</code>.
 	</div>
 		
 	<div id="ldpr-4_4_2" class="rule">4.4.2 LDPR clients SHOULD use the HTTP <code>If-Match</code>
@@ -512,38 +506,38 @@
 		whose predicates the server does not recognize or otherwise chooses
 		not to persist. In other words, LDPR servers MAY restrict themselves
 		to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates 
-		when their intent is to perform a later HTTP PUT to update the resource.
+		when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
 	</div>
-	<div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client MUST preserve all triples retrieved using HTTP GET that
+	<div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client MUST preserve all triples retrieved using HTTP <code>GET</code> that
 		it doesn’t change whether it understands the predicates or not, when
-		its intent is to perform an update using HTTP PUT.  The use of HTTP
-		PATCH instead of HTTP PUT for update avoids this burden for clients
+		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
+		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
 		[[RFC5789]].
 	</div>
-	<div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP PUT.
+	<div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
 	</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_10">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
 	</div>		
 </section>
 		
 <section>
 <h2 id="ldpr-HTTP_DELETE">HTTP DELETE</h2>
-	<p>This specification imposes the following new requirements on HTTP DELETE for LDPRs 
+	<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>
-	<p>Additional requirements on HTTP DELETE of LDPRs within containers can be found in
+	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
 	<a href="ldpc-HTTP_DELETE">section 5.6</a>.</p>
 		
-	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the Request-URI.
-		After a successful HTTP DELETE, a subsequent HTTP GET on the same
-		Request-URI MUST result in a 404 (Not found) or 410 (Gone) status
+	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
+		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
+		<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
 		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
 	</div>
 	
 	<div id="ldpr-4_5_2" class="rule">4.5.2 LDPR servers MAY alter the state of other resources as a result of an
-		HTTP DELETE request. For example, it is acceptable for the server to
+		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
 		remove triples from other resources whose subject or object is the
 		deleted resource. It is also acceptable and common for LDPR servers to
 		not do this – behavior is server application specific.
@@ -553,32 +547,32 @@
 <section>
 <h2 id="ldpr-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.  
+		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
 		Thus, implementers should also carefully read the
 		<a href="#ldpr-HTTP_GET">GET section</a>.</p>
-	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP HEAD method.</div>
+	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
 	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in section <a href="#ldpr-HTTP_OPTIONS">4.8 HTTP OPTIONS</a>.
 	</div>
 </section>
 
 <section>
 <h2 id="ldpr-HTTP_PATCH">HTTP PATCH</h2>
-	<p>This specification imposes the following new requirements on HTTP PATCH for LDPRs 
+	<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>
 		
-	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP PATCH to allow modifications,
+	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
 		especially partial replacement, of their resources [[!RFC5789]]. No
 		minimal set of patch document formats is mandated by this document.
 	</div>
 
 	<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_10">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_9">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.
-		<a href="#ldpc-HTTP_POST">POST (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT">PUT</a> should be used as the standard way to create new LDPRs.
+	<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
+		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
 	</div>
 	
 	<div class="ldp-issue-pending">
@@ -586,7 +580,7 @@
 	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
 	</div>
 
-	<div id="ldpr-4_7_4" class="rule">4.7.4 LDPR servers that support PATCH MUST
+	<div id="ldpr-4_7_4" class="rule">4.7.4 LDPR servers that support <code>PATCH</code> MUST
 		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
 		requests, listing patch document media type(s) supported by the server.
 	</div>
@@ -612,7 +606,7 @@
 		
 	<div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers MUST indicate their support for HTTP Methods by
 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
-		Method tokens in the HTTP response header “<code>Allow</code>”.
+		Method tokens in the HTTP response header <code>Allow</code>.
 	</div>
 		
 </section>
@@ -735,10 +729,10 @@
 
 <section>
 <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>
+<p>In addition to the requirements set forth in section (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.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, 
+		pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>, 
 		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]]. 
 		This is the mechanism by which clients discover the URL of the first page.  If no such <code>Link</code>
@@ -841,7 +835,7 @@
 	<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
-	<em>any</em> triples beyond those found at the HTTP <code>request-URI</code>.
+	<em>any</em> triples beyond those found at the HTTP <code>Request-URI</code>.
 	</p>
 	<ul>
 	<li><p>
@@ -892,11 +886,11 @@
 		one triple for each inlined resource, 
 		whose subject is the <code>ldp:Page</code> resource URI,
 		whose predicate is <code>ldp:inlinedResource</code>, and
-		whose object is the HTTP <code>request-URI</code> of an inlined resource [[!HTTP11]].
+		whose object is the HTTP <code>Request-URI</code> of an inlined resource [[!HTTP11]].
 	</div>
 
 	<div id="ldpc-4_10_2_3" class="rule">4.10.2.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
-		against any resource whose HTTP <code>request-URI</code> is the object of a triple of the form 
+		against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form 
 		described in <a href="#ldpc-4_10_2_2">section 4.10.2.2</a>, unless there are application-specific
 		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
 		of any inlined resource(s) may have changed due to subsequent requests.
@@ -905,8 +899,8 @@
 	<div id="ldpc-4_10_2_4" class="rule">4.10.2.4 LDPR clients MUST NOT assume that LDPR representations
 		lacking a <code>ldp:Page</code> resource or lacking the triple
 		described in <a href="#ldpc-4_10_2_2">section 4.10.2.2</a> contain all the triples for any resource(s)
-		listed in the representation whose HTTP <code>request-URI</code> differs from 
-		the HTTP <code>request-URI</code> used by the client.  
+		listed in the representation whose HTTP <code>Request-URI</code> differs from 
+		the HTTP <code>Request-URI</code> used by the client.  
 		The representation might in fact contain all such triples, or some
 		subset of them, and that might or might not be completely adequate for the client's intended usage, but
 		an LDP client has no way to discern from such a representation which interpretation is accurate.
@@ -1313,7 +1307,7 @@
 		additional triples whose subjects are the members of the container,
 		or that are from the representations of the members (if they have RDF
 		representations). This allows a LDPC server to provide clients with
-		information about the members without the client having to do a GET
+		information about the members without the client having to do a <code>GET</code>
 		on each member individually.  See section <a href="#ldpc-member_data">5.1.1 Container
 		Member Information</a> for additional details.
     </div>
@@ -1327,7 +1321,7 @@
 	</div>
 
 	<div id="ldpc-5_2_9" class="rule">5.2.9 LDPC servers SHOULD NOT re-use URIs, 
-		regardless of the mechanism by which members are created (POST, PUT, etc.).
+		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
 		Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
 		URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
 		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
@@ -1339,7 +1333,7 @@
 	    URIs minted upon LDPC member creation, for example URIs with non-empty fragment identifier [[RFC3986]]. 
 	    To determine which object URI to use for the  membership triple, LDPC's MUST contain triple whose
 	    subject is the LDPC URI, predicate is <code>ldp:membershipObject</code>, with an object <var>MO</var>. 
-	    Where <var>MO</var> and the HTTP URI <var>R</var> from POST create (as found in HTTP response <code>Location</code> header) can be 
+	    Where <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create (as found in HTTP response <code>Location</code> header) can be 
 	    used to locate a triple of the form: <var>(R, MO, N)</var> and 
 	    where <var>N</var> can be used to construct the membership triple of the form: <var>(membership subject, membership predicate, N)</var>.
 	    When <code>ldp:membershipPredicateInverse</code> is used instead of <code>ldp:membershipPredicate</code>, the membership triple MUST be
@@ -1397,7 +1391,7 @@
 		whose predicate is <code>ldp:containerSortCriteria</code>, 
 		and whose object is a <code>rdf:List</code> of
 		<code>ldp:containerSortCriterion</code> resources.  
-		The resulting order MUST be as defined by SPARQL SELECT’s ORDER BY clause 
+		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
 		[[!SPARQL-QUERY]].
 		Sorting criteria MUST be the same for all pages of a representation; if
 		the criteria were allowed to vary, the ordering among members of a container
@@ -1418,7 +1412,7 @@
 		and whose object is 
 		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
 		The only predicate data types whose behavior LDP constrains are those defined
-		by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].  Other data types
+		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
 		can be used, but LDP
 		assigns no meaning to them and interoperability will be limited.
 	</div>
@@ -1475,25 +1469,25 @@
 
 <section>
 <h2 id="ldpc-HTTP_POST">HTTP POST</h2>
-	<p>This specification imposes the following new requirements on HTTP POST for LDPCs 
+	<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>
 		
 	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
-		the entity body of the HTTP POST to a known LDPC. If the resource was created successfully, LDPC servers MUST
+		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, LDPC servers MUST
 		respond with status code 201 (Created) and the <code>Location</code>
 		header set to the new resource’s URL. Clients shall not expect any representation in the response
 		entity body on a 201 (Created) response.
 	</div>
 
-	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST
+	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
 		appear as a member of the LDPC until the new resource is deleted or
 		removed by other methods. An LDPC MAY also contain resources that were
 		added through other means - for example through the user interface of
 		the site that implements the LDPC.
 	</div>
 	
-	<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP POST of non-RDF representations for
+	<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP <code>POST</code> of non-RDF representations for
 		creation of any kind of resource, for example binary resources.
 	</div>
 	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
@@ -1525,15 +1519,15 @@
 	<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_10">enable simple creation and modification</a> of LPDRs.
+		<a href="#ldpr-4_1_9">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
+		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
 		no new requirements to this usage, so its presence functions as a client hint to the server 
 		providing a desired string to be incorporated into the server's final choice of resource URI.
 	</div>
 	
-	<div id="ldpc-5_4_11" class="rule">5.4.11 LDPC servers that allow member creation via POST 
+	<div id="ldpc-5_4_11" class="rule">5.4.11 LDPC servers that allow member creation via <code>POST</code> 
 		SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
 		general requirements on LDPCs</a>.
 	</div>
@@ -1546,7 +1540,7 @@
 	
 	<div class="ldp-issue-pending">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/80">ISSUE-80</a></div>
-	How does a client know which POST requests create new resources.
+	How does a client know which <code>POST</code> requests create new resources.
 	<p>
 	Note from editor: the MUST here keeps this aligned with what we decided for OPTIONS on PATCH;  in both 
 	cases the header registration says SHOULD, and the LDP spec says MUST.  What makes that look a bit odd is
@@ -1590,16 +1584,16 @@
 
 <section>
 <h2 id="ldpc-HTTP_PUT">HTTP PUT</h2>
-	<p>This specification imposes the following new requirements on HTTP PUT for LDPCs 
+	<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>
 		
-	<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDPC’s members; 
+	<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s members; 
 		if the server receives such a request, it SHOULD respond with a 409
 		(Conflict) status code.
 	</div>
 	<div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using
-		HTTP PUT on a corresponding <a>non-member resource</a>, which
+		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
 		MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
 		and <code>ldp:membershipPredicateInverse</code>.
 		Section <a href="#ldpc-5_7_1">5.7.1 HTTP HEAD</a> describes the process by which clients
@@ -1607,13 +1601,13 @@
 
 	</div>
 	    
-    <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP PUT requests
+    <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
 		with member information in the request representation.
 		See section <a href="#ldpc-member_data">5.1.1 Container
 		Member Information</a> for additional details.
 	</div>
 	
-	<div id="ldpc-5_5_4" class="rule">5.5.4 LDPC servers that allow member creation via PUT 
+	<div id="ldpc-5_5_4" class="rule">5.5.4 LDPC servers that allow member creation via <code>PUT</code> 
 		SHOULD NOT re-use URIs, per the <a href="#ldpc-5_2_9">
 		general requirements on LDPCs</a>.
 	</div>
@@ -1622,17 +1616,17 @@
 
 <section>
 <h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
-	<p>This specification imposes the following new requirements on HTTP DELETE for LDPRs 
+	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
 		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>
 		
 	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
-	    was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
+	    was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
 		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
 		the LDPC by removing the corresponding membership triple.
 	</div>	
-	<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC, it MUST remove any
-		membership triples associated with the LDPC as indicated by the canonical Request-URI.  The LDPC server MAY perform additional removal 
+	<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC server successfully completes the <code>DELETE</code> request on a LDPC, it MUST remove any
+		membership triples associated with the LDPC as indicated by the canonical <code>Request-URI</code>.  The LDPC server MAY perform additional removal 
 		of member resources. 
 		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
 		been accessed for some period of time.
@@ -1649,7 +1643,7 @@
 	</div>	
 	
 	<div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose 
-	representation was HTTP POST'd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
+	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
 	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>	
 	
@@ -1658,26 +1652,26 @@
 <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
+		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPR servers must also include HTTP headers
+		on response to <code>OPTIONS</code>, see <a href="#ldpr-4_6_2">4.6.2</a>.
+		Thus, implementers supporting <code>HEAD</code> 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>
 <h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
-	<p>This specification imposes the following new requirements on HTTP PATCH for LDPCs 
+	<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>
 		
-	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
+	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
 		method for updating LDPC non-membership properties.
 	</div>
 </section>
 
 <section>
 <h2 id="ldpc-HTTP_OPTIONS">HTTP OPTIONS</h2>
-	<p>This specification imposes the following new requirements on HTTP OPTIONS for LDPCs.
+	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
 		</p>
 
 	<div id="ldpc-5_9_1" class="rule">5.9.1  
@@ -1687,7 +1681,7 @@
 		without retrieving a full representation including all of its members; 
 		see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
 		examples. 
-		In responses to <code>OPTIONS</code> requests with an LDPC as the Request-URI, 
+		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
 		LDPC servers that define a non-member resource SHOULD provide an HTTP <code>Link</code>
 		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
 		<code>http://www.w3.org/ns/ldp#non-member-resource</code> [[!RFC5988]]. 
@@ -1702,7 +1696,7 @@
 	</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 
-	representation was HTTP POST'd to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
+	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
 	header whose target URI is the associated LDPR, and whose link relation type is 
 	<code>meta</code> [[!RFC5988]].</div>
@@ -1764,7 +1758,7 @@
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
 		Action 88: Add a property ldp:membersInlined true/false. The default (if not specified) is false. 
 		If true, it means that a complete description of all members [on the current page] are inlined with the container document [or page], 
-		and therefore clients SHOULD NOT do GET on the member URIs to retrieve additional triples.
+		and therefore clients SHOULD NOT do <code>GET</code> on the member URIs to retrieve additional triples.
 		marked as AT RISK.
 	</div>
 
@@ -1884,7 +1878,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 4.1.5, section number fixup:4.1.8-13-&gt;6-11, 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>
@@ -1987,21 +1981,9 @@
 <ul>
 	<li>(IN)Consistency issues
 <ul>
-	<li><a href="#ldpr-inlining" class="sectionRef"></a> + probably other sections say things like "LDP does not provide clients...".  
-	Should those read "LDP 1.0..." instead?
-	</li><a href="#ldpr-inlining" class="sectionRef"></a>
-		we have a mix of way we reference HTTP verbs, in this section (and a few others) we have "<code>GET</code>" vs. "GET".
-	<li><a href="#ldpr-inlining" class="sectionRef"></a>
-		request-URI or Request-URI
-	</li>
-	<li><a href="#ldpr-inlining" class="sectionRef"></a>
-		wonder how consistent we are with formatting headers (we should search/replace to keep them all the same
-	</li>
 	<li><a href="#ldpc-inlining" class="sectionRef"></a>
 		"LDPC Servers" and "LDP Clients" other areas we use lowercase form of servers and clients...we should agree on one and use it
 	</li>
-	<li>using specref's "informative" styling instead of hard-wiring
-	</li>
 	<li>using "sectionRef" instead of hardwiring
 	</li>
 	<li>update ldpc samples with all required props