Fixed biblirefs, consistency items and moved editor todo into comments
authorsspeiche
Sun, 14 Jul 2013 22:45:26 -0400
changeset 194 b6d66196a02d
parent 192 221002315344
child 195 ef7c14664b1f
Fixed biblirefs, consistency items and moved editor todo into comments
ldp.html
--- a/ldp.html	Thu Jul 11 16:52:09 2013 -0400
+++ b/ldp.html	Sun Jul 14 22:45:26 2013 -0400
@@ -1,4 +1,11 @@
 <!DOCTYPE html>
+<!-- 
+ Editor TODO:
+   - Incorporate ISSUE-37 text from Ashok
+   - Fix up LDPR paging sample to remove container
+   - Should we remove / hide "Change History" section?
+   - Generate HTML DIFF version
+ -->
 <html>
   <head>
     <title>Linked Data Platform 1.0</title>
@@ -192,6 +199,12 @@
 	narrow to provide a set of key rules for reading and writing Linked
 	Data that most, if not all, other specifications will depend upon and
 	implementations will support.</p>   
+	
+	<div class="ldp-issue-open">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>
+	Additional introductory text on the LDP data and interaction model <em>-- awaiting contribution</em>
+	</div>
+	
 </section>
 	
 <section>
@@ -210,7 +223,7 @@
 	
 	<dt><dfn>Linked Data Platform Resource</dfn> (<dfn><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
 	<dd>HTTP resource whose state is represented in RDF that conforms to the simple lifecycle
-		patterns and conventions in the <a href="#ldpr">LDPRs</a> section.<p></p></dd>
+		patterns and conventions in the <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
 		
 	<dt><dfn>Linked Data Platform Container</dfn> (<dfn><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
 	<dd>An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
@@ -296,19 +309,20 @@
   <li>3. Conformance: <b>normative</b></li>
   <li>4. Linked Data Platform Resources: <b>normative</b></li>
   <li>5. Linked Data Platform Containers: <b>normative</b></li>
-  <li>A. Acknowledgements: <b>normative</b></li> 
-  <li>B. Change History: <b>normative</b></li>
-  <li>D.1 Normative references: <b>normative</b></li>
-  <li>D.2 Informative references: <b>informative</b></li>
+  <li>6. HTTP Header Definitions: <b>normative</b></li>
+  <li>A. Acknowledgements: <b>informative</b></li> 
+  <li>B. Change History: <b>informative</b></li>
+  <li>C.1 Normative references: <b>normative</b></li>
+  <li>C.2 Informative references: <b>informative</b></li>
 </ul>
 
-<p>A conforming <b>LDP Server</b> is an application program that processes HTTP 
-requests and generates HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
-and <a href="#linked-data-platform-containers">LDPCs</a>.</p>
+<p>A conforming <b>LDP server</b> is an application program that processes HTTP 
+requests and generates HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
+and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>
 
-<p>A conforming <b>LDP Client</b> is an application program that generates HTTP 
-requests and processes HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
-and <a href="#linked-data-platform-containers">LDPCs</a>.</p>
+<p>A conforming <b>LDP client</b> is an application program that generates HTTP 
+requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
+and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>
 
 </section>
 
@@ -465,7 +479,7 @@
 	<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 <code>POST</code> 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 <a href="#ldpc-HTTP_POST" class="sectionRef"></a>
 	 in the LDPC parent section for more details.</p>
 </section>
 
@@ -548,10 +562,10 @@
 <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
 		<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>
+		Thus, implementers should also carefully read 
+		<a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
 	<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 id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 	</div>
 </section>
 
@@ -729,7 +743,7 @@
 
 <section>
 <h3 id="ldpr-PagingGET">HTTP GET</h3>
-<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>
+<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 <code>Request-URI</code>, 
@@ -741,11 +755,11 @@
 		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>.
 		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.
+		the URL for the next page. See <a href="#ldpr-paging" class="sectionRef"></a> for additional details.
 	</div>
 	<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
+		server-initiated paging. See <a href="#ldpr-paging" class="sectionRef"></a> for
 		additional details.
 	</div>
 	<div id="ldpr-pagingGET-3" class="rule">4.9.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
@@ -859,7 +873,7 @@
 <section>
 <h3 id="ldpr-InliningGET">HTTP GET</h3>
 	<p>In addition to the requirements set forth in other sections, 
-		LDPR Servers that support <a>resource inlining</a>
+		LDPR servers that support <a>resource inlining</a>
 		must also follow the requirements in this section.</p>
 
 	<div class="ldp-issue-pending">
@@ -868,7 +882,7 @@
 	marked as AT RISK.
 	</div>
 
-	<div id="ldpr-4_10_2_1" class="rule">4.10.2.1 LDPR servers that support <a>resource inlining</a> MUST 
+	<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers that support <a>resource inlining</a> MUST 
 		include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources, 
 		whether or not the representation contains subsequent pages.  The <code>ldp:Page</code> resource conceptually contains
 		metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
@@ -881,24 +895,24 @@
 		requests for them.
 	</div>
 
-	<div id="ldpr-4_10_2_2" class="rule">4.10.2.2 LDPR servers that support <a>resource inlining</a> MUST 
-		include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_10_2_1">section 4.10.2.1</a> 
+	<div id="ldpr-4_10_3_2" class="rule">4.10.3.2 LDPR servers that support <a>resource inlining</a> MUST 
+		include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a> 
 		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]].
 	</div>
 
-	<div id="ldpc-4_10_2_3" class="rule">4.10.2.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
+	<div id="ldpc-4_10_3_3" class="rule">4.10.3.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 
-		described in <a href="#ldpc-4_10_2_2">section 4.10.2.2</a>, unless there are application-specific
+		described in <a href="#ldpc-4_10_3_2">section 4.10.3.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.
 	</div>
 
-	<div id="ldpc-4_10_2_4" class="rule">4.10.2.4 LDPR clients MUST NOT assume that LDPR representations
+	<div id="ldpc-4_10_3_4" class="rule">4.10.3.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)
+		described in <a href="#ldpc-4_10_3_2">section 4.10.3.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.  
 		The representation might in fact contain all such triples, or some
@@ -1534,7 +1548,7 @@
 	
 	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
 	201-Created and URI indicated by <code>Location</code> response header), LDPC servers MAY create an associated LDPR
-	to contain data about the created resource.  If an LDPC Server creates this associated LDPR it MUST indicate
+	to contain data about the created resource.  If an LDPC server creates this associated LDPR it MUST indicate
 	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
 	and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].</div>	
 	
@@ -1655,7 +1669,7 @@
 		<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>
+		<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
 </section>
 
 <section>
@@ -1749,8 +1763,8 @@
 <section>
 <h3 id="ldpc-InliningGET">HTTP GET</h3>
 	<p>In addition to the requirements set forth in other sections, 
-		LDPC Servers that support <a>member inlining</a>,
-		and LDP Clients aware of the same facility,
+		LDPC servers that support <a>member inlining</a>,
+		and LDP clients aware of the same facility,
 		must also follow the requirements in this section.
 	</p>
 
@@ -1764,7 +1778,7 @@
 
 	<div id="ldpc-5_10_2_1" class="rule">5.10.2.1 LDPC representations that are <a title="member inlining">member inlined</a> MUST 
 		include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
-		multiple pages, as described in <a href="#ldpr-4_10_2_1">section 4.10.2.1</a>.  In addition to satisfying
+		multiple pages, as described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a>.  In addition to satisfying
 		those requirements, the representation MUST contain a triple
 		whose subject is the <code>ldp:Page</code> resource URI,
 		whose predicate is <code>ldp:membersInlined</code>, and
@@ -1973,30 +1987,6 @@
 </ul>
 <blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote>
 </section>
-
-<section class='appendix informative' id="todos">
-<h1>Editor Todos and Notes</h1>
-<p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
-editors use.  They have no meaning in final product of a published working draft and will be removed prior to publishing.</p>
-<ul>
-	<li>(IN)Consistency issues
-<ul>
-	<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 "sectionRef" instead of hardwiring
-	</li>
-	<li>update ldpc samples with all required props
-	</li>
-</ul>
-	</li>
-</ul>
-	<div class="ldp-issue-open">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>
-	Additional introductory text on the LDP data and interaction model
-	</div>
-</section>
-
     
   </body>
 </html>