--- a/ldp.html Thu Jul 11 14:26:05 2013 -0400
+++ b/ldp.html Thu Jul 11 15:16:58 2013 -0400
@@ -380,18 +380,18 @@
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
</div>
- <div id="ldpr-4_1_8" class="rule">4.1.8 LDPR servers MAY support standard representations beyond those
+ <div id="ldpr-4_1_7" class="rule">4.1.7 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_9" class="rule">4.1.9 LDPRs MAY be created, updated and deleted using methods not defined in
+ <div id="ldpr-4_1_8" class="rule">4.1.8 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_10" class="rule">4.1.10 LDPR server responses MUST use entity tags (either weak or strong
+ <div id="ldpr-4_1_9" class="rule">4.1.9 LDPR server responses MUST use entity tags (either weak or strong
ones) as response <code>ETag</code> header values.
</div>
@@ -400,7 +400,7 @@
How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
</div>
- <div id="ldpr-4_1_11" class="rule">4.1.11 LDPR
+ <div id="ldpr-4_1_10" class="rule">4.1.10 LDPR
servers SHOULD enable simple creation and modification of LDPRs.
It is
common for LDPR servers to put restrictions on representations – for
@@ -417,7 +417,7 @@
How can a client determine that it is in communication with an LDP server?
</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 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>)
@@ -436,7 +436,7 @@
inferencing levels
</div>
- <div id="ldpr-4_1_13" class="rule">4.1.13 LDPR servers
+ <div id="ldpr-4_1_12" class="rule">4.1.12 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
@@ -524,7 +524,7 @@
</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_11">enable simple creation and modification</a> of LPDRs.
+ This is a consequence of the requirement to <a href="#ldpr-4_1_10">enable simple creation and modification</a> of LPDRs.
</div>
</section>
@@ -574,7 +574,7 @@
<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_11">enable simple creation and modification</a> of LPDRs.
+ This is a consequence of the requirement to <a href="#ldpr-4_1_10">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.
@@ -739,7 +739,7 @@
<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>
- <div id="ldpr-5_3_4" class="rule">5.3.4 LDPR servers SHOULD allow clients to retrieve large LDPRs in
+ <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,
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]].
@@ -751,29 +751,29 @@
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.
</div>
- <div id="ldpc-5_3_5" class="rule">5.3.5 LDPR servers MAY split the response representation of any LDPR.
+ <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
additional details.
</div>
- <div id="ldpc-5_3_5_1" class="rule">5.3.5.1 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
+ <div id="ldpr-pagingGET-3" class="rule">4.9.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
by redirecting the client to the first page resource using a <code>303 See
Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
</div>
- <div id="ldpc-5_3_6" class="rule">5.3.6 LDPR servers that support paging MUST include in the page
+ <div id="ldpr-pagingGET-4" class="rule">4.9.2.4 LDPR servers that support paging MUST include in the page
representation a representation for the LDPR, such that:
</div>
- <div id="ldpc-5_3_6_1" class="rule">5.3.6.1 The page resource representation SHOULD have one triple to indicate its
+ <div id="ldpr-pagingGET-5" class="rule">4.9.2.5 The page resource representation SHOULD have one triple to indicate its
type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
It also SHOULD have 1 triple to indicate the resource it is paging,
whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
and object is the URL of the LDPC.
</div>
- <div id="ldpc-5_3_6_2" class="rule">5.3.6.2 The page resource representation MUST have one triple with the subject
+ <div id="ldpr-pagingGET-6" class="rule">4.9.2.6 The page resource representation MUST have one triple with the subject
of the page, predicate of <code>ldp:nextPage</code> and
object being the URL for the subsequent page.
</div>
- <div id="ldpc-5_3_6_3" class="rule">5.3.6.3 The last page resource representation MUST have one triple with the subject of the
+ <div id="ldpr-pagingGET-7" class="rule">4.9.2.7 The last page resource representation MUST have one triple with the subject of the
last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
</div>
</section>
@@ -1398,7 +1398,7 @@
<a href="#ldpc-5_2_3">5.2.3</a>.
</div>
- <div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
+ <div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
order. If the server does so, it MUST be specify the order using a triple
whose subject is the page URI,
whose predicate is <code>ldp:containerSortCriteria</code>,
@@ -1416,7 +1416,7 @@
an example.
</div>
- <div id="ldpc-5_3_8" class="rule">5.3.8 LDPC page representations
+ <div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
a triple
@@ -1430,7 +1430,7 @@
assigns no meaning to them and interoperability will be limited.
</div>
- <div id="ldpc-5_3_9" class="rule">5.3.9 LDPC page representations
+ <div id="ldpc-5_3_4" class="rule">5.3.4 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
a triple
@@ -1449,7 +1449,7 @@
referring readers to SPARQL 1.1. Which normative reference do we want?
</div>
- <div id="ldpc-5_3_10" class="rule">5.3.10 LDPC page representations
+ <div id="ldpc-5_3_5" class="rule">5.3.5 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MAY contain,
in any <code>ldp:containerSortCriterion</code> list entry,
a triple
@@ -1532,7 +1532,7 @@
<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_11">enable simple creation and modification</a> of LPDRs.
+ <a href="#ldpr-4_1_10">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
@@ -1850,8 +1850,8 @@
resource identified by the <code>Request-URI</code>.
</div>
-<section>
-<h3 id="header-accept-post-iana">IANA Registration Template</h3>
+ <div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
+ <div>
<blockquote>
<p>
The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
@@ -1869,7 +1869,7 @@
Specification document: this specification
</p>
</blockquote>
-</section>
+ </div>
</section>
</section> <!-- Header defns -->
@@ -1899,6 +1899,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->7-12, 4.9.2.* fixup, 5.3.7-10->>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>
@@ -2018,8 +2019,6 @@
</li>
<li>using "sectionRef" instead of hardwiring
</li>
- <li>using respec section labeling consistently
- </li>
<li>update ldpc samples with all required props
</li>
</ul>