--- 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><resourceURL>?theFirstPage</code>, then the corresponding link header
would be <code>Link: <?theFirstPage>;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>