--- a/ldp-paging.html Mon Jul 28 14:29:21 2014 -0400
+++ b/ldp-paging.html Tue Jul 29 13:07:14 2014 -0400
@@ -314,7 +314,7 @@
<p>
When a <a>paged resource</a> is also an LDPC, some additional efficiencies become possible in cases
where the server predictably assigns members to pages and is able to communicate its assignment
- algorithm to clients. The <a href="#ldpc" class="sectionRef"></a> defines a facility is to communicate
+ algorithm to clients. The <a href="#ldpc" class="sectionRef"></a> defines a facility to communicate
the sort order of member-to-page assignments, to handle that common implementation algorithm.
</p>
<p>
@@ -437,7 +437,7 @@
<dd>A link to the next <a title="In-sequence page resource">in-sequence page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
- header [[!RFC5988]][[!HTML5]] where
+ header [[!RFC5988]] where
the context URI identifies some <var>P<sub>i=1 (first)...n-1 (next to last)</sub></var> and
the target URI identifies <var>P<sub>i+1</sub></var>.
<p></p></dd>
@@ -457,7 +457,7 @@
<dd>A link to the previous <a title="In-sequence page resource">in-sequence page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
- header [[!RFC5988]][[!HTML5]] where
+ header [[!RFC5988]] where
the context URI identifies some <var>P<sub>i=2...n (last)</sub></var> and
the target URI identifies <var>P<sub>i-1</sub></var>.
<p></p></dd>
@@ -574,7 +574,6 @@
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -639,19 +638,19 @@
<p>
The simplest possible solution would be to redefine the meaning of the existing
URI <code>http://example.org/customer-relations</code> from "all customer relations information"
- to "the first chunk of all customer relations information". This would require changes to
+ to "the first subset of all customer relations information". This would require changes to
any existing clients whose code was built using the original definition however, so it's
- more likely that Example Co. would mint a new URI for "the first chunk", define a way to
- find subsequent chunks, and have clients use this new protocol.
+ more likely that Example Co. would mint a new URI for "the first subset", define a way to
+ find subsequent subsets, and have clients use this new protocol.
</p>
<p>
The new protocol does not solve the problem of migrating existing clients from the old
- "all" to the new "first chunk" semantic; neither would a <code>303 See Other</code> redirect
+ "all" to the new "first subset" semantic; neither would a <code>303 See Other</code> redirect
from the old to the new URI, given the
<a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">widespread historical client practice</a> of automatically
following <code>303</code> redirects and treating the redirected-to resource as equivalent
to the original. The safe route is to have clients explicitly tell the server that they
- are capable of handling the "first chunk" semantic on the redirected-to URI; this is what
+ are capable of handling the "first subset" semantic on the redirected-to URI; this is what
LDP Paging does.
</p>
<p>
@@ -676,12 +675,11 @@
<pre class="example" id="ldpp-ex-paging-303-resp1">
HTTP/1.1 303 See Other
Location: <http://example.org/customer-relations?page1>
-Transfer-Encoding: chunked
</pre>
<p>
At this point the client does not know if the target
- resource is "all" or "the first chunk"; it has to retrieve the resource to know.
+ resource is "all" or "the first subset"; it has to retrieve the resource to know.
</p>
<em>Request</em>
@@ -704,7 +702,6 @@
Link: <http://example.org/customer-relations?p=2>; rel='next'
Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -786,7 +783,6 @@
<http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -891,7 +887,6 @@
Link: <http://example.org/customer-relations?p=2>; rel='next'
Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -990,7 +985,6 @@
<http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -1125,6 +1119,8 @@
if the response also indicates that the <a title="Paged resource">paged resource's</a>
<a href="#ldpr-notify-changes">state has <i>not</i> changed</a>
while the client was traversing its <a title="In-sequence page resource">pages</a>.
+ Servers might also limit the lifetime of a particular page sequence, and client requests after the server has
+ abandoned that sequence are likely to result in <code>410 Gone</code> or other <code>4xx</code> status codes.
</blockquote>
</section>
@@ -1437,10 +1433,17 @@
<section id="ldpr-pagingGET-sequences-change"><h2 class="normal">
<a title="LDP Paging server">LDP Paging servers</a> MAY
add or remove <a title="in-sequence page resource">in-sequence page resources</a> to a
- <a title="Paged resource">paged resource's</a> sequence over time,
- but SHOULD only add pages to the end of a sequence.
+ <a title="Paged resource">paged resource's</a> sequence over time.
+ If the page sequence is <a href="#ldpc-HTTP_GET">ordered</a>, then the ordering communicated by the server MUST be maintained;
+ the server SHOULD only add pages to the end of an unordered sequence.
</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
<blockquote><em>Non-normative note:</em>
+ Servers might abandon an ordered page sequence, resulting in <code>4xx</code> status codes to subsequent requests,
+ although it will be less disruptive to clients if the server either adds content to the appropriate existing page or
+ adds new pages at the proper point in the sequence. Clients have no more efficient means than a conditional retrieval
+ request on existing pages to detect the changed/added pages.
+ </blockquote>
+ <blockquote><em>Non-normative note:</em>
As a result, clients retrieving any <a>in-sequence page resource</a> several times can observe its place in the sequence
change as the state of the <a>paged resource</a> changes.
For example, a nominally last page's server might provide a
@@ -1588,23 +1591,24 @@
Since more than one value may be used to sort members,
the LDPC specification allows servers to assert the ordered list
of sort criteria used to sort the members, using the
- <code>ldp:containerSortCriteria</code> relation.
- Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>,
- consisting of a <code>ldp:containerSortOrder</code>,
- <code>ldp:containerSortPredicate</code>, and
- optionally a <code>ldp:containerSortCollation</code>.
+ <code>ldp:pageSortCriteria</code> HTTP link relation.
+ Each member of the ordered list exposes one <code>ldp:pageSortCriterion</code>,
+ consisting of a <code>ldp:pageSortOrder</code>,
+ <code>ldp:pageSortPredicate</code>, and
+ optionally a <code>ldp:pageSortCollation</code>.
</p>
<p>
- Here is an example asset container described in [[LDP]] section 5.1,
- with the ordering of the assets asserted:</p>
+ Here is an example asset container described in [[LDP]] section 5.1:
+ </p>
<em>Request</em>
<pre class="example">GET /netWorth/nw1/assetContainer/ HTTP/1.1
Host: example.org
Accept: text/turtle
+Prefer: return=representation; page-size="500 rdf-triples"
</pre>
<p>
- The server responds with status code <code>200 OK</code>,
+ The server might respond with status code <code>200 OK</code>,
and the following representation:
</p>
@@ -1616,7 +1620,6 @@
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type"
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
# The following is the ordered representation of
# http://example.org/netWorth/nw1/assetContainer/
@@ -1634,14 +1637,6 @@
ldp:insertedContentRelation ldp:MemberSubject;
ldp:contains <a1>, <a2>, <a3>.
-<?firstPage>
- ldp:containerSortCriteria (<#SortValueAscending>).
-
-<#SortValueAscending>
- a ldp:ContainerSortCriterion;
- ldp:containerSortOrder ldp:Ascending;
- ldp:containerSortPredicate o:value.
-
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset <a1>, <a3>, <a2>.
@@ -1657,20 +1652,15 @@
o:value 100.00 .
</pre>
<p>
- As you can see, the <code>ldp:ContainerSortCriteria</code> predicate has been added.
- The <code>ldp:ContainerSortCriteria</code>
- predicate asserts that the <code>o:value</code> predicate will be used <em>when the container is paged</em>
- to assign sets of members to pages in ascending order.
- <em>Since the resource above was not paged, in this instance it conveys no useful information
- to the client.</em>
- Observe that the representation above does not have the values sorted either;
- this is fine (although other permutations are possible), since the LDP sort criteria
- conveys nothing about the order of members within any single resource or representation.
+ The client knows that LDP Paging was not used to form the response, because the HTTP status code is <code>200 OK</code>
+ and there is no <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code> response header.
+ Since paging was not used, the server provides no information related to page sorting;
+ providing page sorting information would have no value to the client, it would only waste resources.
</p>
-
+
<p>
- Had the server responded instead with a redirect to a first page,
- whose representation was (after following a redirect):
+ Had the server responded instead with a redirect to a first page <code>http://example.org/netWorth/nw1/assetContainer/?p=1</code>,
+ whose representation was (after following the redirect):
</p>
<em>Response:</em>
@@ -1682,12 +1672,12 @@
<http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/netWorth/nw1/assetContainer/?p=2>; rel='next'
Link: <http://example.org/netWorth/nw1/assetContainer/>; rel='canonical'; etag="v1"
+Link: <http://example.org/netWorth/nw1/assetContainer/pageSortOrder/>; rel='http://www.w3.org/ns/ldp#pageSortCriteria'
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
# The following is the ordered representation of
# http://example.org/netWorth/nw1/assetContainer/ page 1 of 2
-<!-- @base is required here ; any use for paste into validators for checking is free bonus -->
+<!-- @base is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
@base <http://example.org/netWorth/nw1/assetContainer/> .
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@@ -1701,14 +1691,6 @@
ldp:insertedContentRelation ldp:MemberSubject;
ldp:contains <a1>, <a2>, <a3>.
-<?firstPage>
- ldp:containerSortCriteria (<#SortValueAscending>).
-
-<#SortValueAscending>
- a ldp:ContainerSortCriterion;
- ldp:containerSortOrder ldp:Ascending;
- ldp:containerSortPredicate o:value.
-
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset <a1>, <a3>, <a2>.
@@ -1716,13 +1698,51 @@
<a1>
a o:Stock;
o:value 100.00 .
+
+# The remainder of the content describes the sort order.
+# Note that the new base URI here matches the target URI of the pageSortCriteria Link header above.
+
+@base <http://example.org/netWorth/nw1/assetContainer/pageSortOrder/> .
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+<!-- (#SortValueAscending) does not work, because the subject uri would be a blank node -->
+<>
+ a rdf:List;
+ rdf:first <#SortValueAscending> ;
+ rdf:rest rdf:nil .
+
+<#SortValueAscending>
+ a ldp:pageSortCriterion;
+ ldp:pageSortOrder ldp:Ascending;
+ ldp:pageSortPredicate o:value.
</pre>
<p>
- Then the client would be guaranteed that the values of <code>o:value</code> all assets
+ In this case the server does provide information on the assignment of members to pages.
+ </p>
+ <ul>
+ <li>
+ A <code>Link rel='http://www.w3.org/ns/ldp#pageSortCriteria'</code> response header has been
+ added, allowing the client to know what sort criteria the server used.
+ </li>
+ <li>
+ The server also chose to include assertions about the sort criteria in the content for the
+ first page, namely the triples occurring after the second <code>@base</code> directive.
+ This is an optional exemplary optimization, and the client must decide for itself using means outside of
+ LDP and HTTP whether or not to trust those assertions.
+ If the client trusts those assertions, it need not retrieve them; retrieving them would in this case
+ result in another <code>HTTP GET</code> request. For the purposes of this example, assume that
+ the assertions match what the client would obtain by retrieving them itself.
+ </li>
+ <li>
+ The contents of the page sort criteria resource
+ asserts that the <code>o:value</code> predicate will be used
+ to assign sets of members to pages in ascending order.
+ The server is telling the client that the values of <code>o:value</code> of all assets
on the first page are no lower than the values on subsequent pages.
Since only one such value happens to fall on the first page, this is trivially satisfied.
- </p>
+ </li>
+ </ul>
+
<p>
When the client retrieves the second page by following the <code>rel='next'</code> link,
its representation might be:
@@ -1735,13 +1755,14 @@
ETag: "_87e52ff291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
<http://www.w3.org/ns/ldp#Page>; rel="type"
-Link: <http://example.org/netWorth/nw1/assetContainer/?firstPage>; rel='prev'
+Link: <http://example.org/netWorth/nw1/assetContainer/?pageSortOrder>; rel='prev'
Link: <http://example.org/netWorth/nw1/assetContainer/>; rel='canonical'; etag="v1"
+Link: <http://example.org/netWorth/nw1/assetContainer/pageSortOrder/>; rel='http://www.w3.org/ns/ldp#pageSortCriteria'
Allow: GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
# The following is the ordered representation of
# http://example.org/netWorth/nw1/assetContainer/ page 2 of 2
+<!-- @base is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
@base <http://example.org/netWorth/nw1/assetContainer/> .
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@@ -1755,7 +1776,19 @@
o:value 100.00 .
</pre>
- <p>
+ <ul>
+ <li>
+ The same <code>Link rel='http://www.w3.org/ns/ldp#pageSortCriteria'</code> response header is present,
+ allowing the client to know what sort criteria the server used.
+ </li>
+ <li>
+ The server chose not to include assertions about the sort criteria in the content for the
+ second page. Since LDP Paging <a href="#ldpc-sort-consistent">requires that the page sequence is sorted consistently</a>,
+ any client that already retrieved the first page has already seen the page sorting criteria. If a client is given
+ the URI of an <a>in-sequence page resource</a> through means other than following links, it always has the option
+ to retrieve the sort criteria.
+ </li>
+ <li>
As the example shows, the values of <code>o:value</code> all assets
on the second page are greater than or equal to the values on earlier pages.
<em>The values within this page are not ordered according to the
@@ -1764,7 +1797,8 @@
to the ordering within any single page's representation.
Typically those representations have not guarantee of ordering and are generated by libraries,
whose serializers do not provide a way to control how the order is conveyed.
- </p>
+ </li>
+ </ul>
<p>
It is up to the domain model
and server to determine the appropriate predicate to indicate the
@@ -1781,34 +1815,56 @@
<section id="ldpc-HTTP_GET">
<h2>HTTP GET requirements for member ordering across pages</h2>
- <section id="ldpc-sortcriteriaobj"><h2 class="normal">
+ <p>
+ If a <a>LDP Paging server</a> chooses to use LDP Paging-defined mechanisms to
+ tell clients the order it uses to assign LDPC members to pages,
+ which is optional, then it does so as described in this section.
+ LDP Paging does not specify ordering for <a title="in-sequence page resource">pages</a> in other cases.
+ See <a href="#ldpc-ordering" class="sectionRef"></a> for
+ exemplary message exchanges.
+ </p>
+
+ <section id="ldpc-sort-criteria-consistent"><h2 class="normal">
<a title="LDP Paging server">LDP Paging servers</a> MAY
- communicate the order it uses to allocate LDPC members to <a>in-sequence page resource</a>s
- as part of the pages' representations;
- LDP Paging does not specify ordering for pages of LDPRs in other cases.
- If the server communicates this, it MUST specify the order using a triple
- whose subject is the page URI,
- 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 <code>SELECT</code>’s <code>ORDER BY</code> clause
- [[!sparql11-query]].
- Sorting criteria MUST be the same for all pages of a representation; if
+ communicate the order used to allocate LDPC members to <a title="in-sequence page resource">pages</a>.
+ If they choose to communicate the order, they MUST respond
+ consistently to retrieval requests for each <a title="in-sequence page resource">page</a> in the same sequence.
+ That is, they must communicate the same criteria (or absence of it) for all pages in the same sequence; if
the criteria were allowed to vary, the ordering among members of a container
- across pages would be undefined.
+ across <a title="in-sequence page resource">pages</a> would be undefined.
+ </h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <blockquote>
+ <em>Non-normative note:</em> A server can offer different sequences for the same <a>paged resource</a>,
+ for example, sequences that have differing sort criteria, and they can be offered serially or concurrently.
+ </blockquote>
+
+ <section id="ldpc-sort-criteria-link"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> MUST
+ specify the order using a <code>HTTP Link</code> header
+ whose context URI is the page URI,
+ whose link relation is <code>http://www.w3.org/ns/ldp#pageSortCriteria</code>,
+ and whose target IRI identifies a page sort criteria resource compliant with this section's requirements on its content.
+ </h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section id="ldpc-sort-criteria-content"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> MUST
+ expose page sort criteria resources that are LDP-RSs, each consisting of a <code>rdf:List</code> of
+ <code>ldp:pageSortCriterion</code> resources.
The first list entry provides the primary
sorting criterion, any second entry provides a secondary criterion used to order members considered
equal according to the primary criterion, and so on.
- See <a href="#ldpc-ordering" class="sectionRef"></a> for
- an example.
+ The resulting page sort order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [[!sparql11-query]].
</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
- <section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MUST contain,
- in every <code>ldp:containerSortCriterion</code> list entry,
+ <section id="ldpc-sortliteraltype"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> MUST
+ expose page sort criteria resources that contain,
+ in every <code>ldp:pageSortCriterion</code> list entry,
a triple
whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:containerSortPredicate</code>
+ whose predicate is <code>ldp:pageSortPredicate</code>
and whose object is
the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
The only literal data types whose behavior LDP constrains are those defined
@@ -1817,43 +1873,57 @@
assigns no meaning to them and interoperability will be limited.
</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
- <section id="ldpc-sortorder"><h2 class="normal">LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MUST contain,
- in every <code>ldp:containerSortCriterion</code> list entry,
+ <section id="ldpc-sortorder"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> MUST
+ expose page sort criteria resources that contain,
+ in every <code>ldp:pageSortCriterion</code> list entry,
a triple
whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:containerSortOrder</code>
+ whose predicate is <code>ldp:pageSortOrder</code>
and whose object describes the order used.
+ <blockquote>
+ <p>
LDP defines two values,
<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
as the object of this triple. Other values can be used, but LDP
assigns no meaning to them and interoperability will be limited.
+ </p>
+ </blockquote>
</h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
- <section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MAY contain,
- in any <code>ldp:containerSortCriterion</code> list entry,
+ <section id="ldpc-sortcollation"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> MAY
+ expose page sort criteria resources that contain,
+ in any <code>ldp:pageSortCriterion</code> list entry,
a triple
whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:containerSortCollation</code>
+ whose predicate is <code>ldp:pageSortCollation</code>
and whose object identifies the collation used.
+ The <code>ldp:pageSortCollation</code> triple MUST be omitted for comparisons
+ involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
+ <blockquote>
+ <p>
LDP defines no values for use
as the object of this triple. While it is better for interoperability to use
open standardized values, any value can be used.
- When the <code>ldp:containerSortCollation</code> triple is absent and the
+ </p>
+ <p>
+ When the <code>ldp:pageSortCollation</code> triple is absent and the
<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
[[!sparql11-query]] using two-argument <code>fn:compare</code>, that is,
it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code>
was the specified collation.
- When the <code>ldp:containerSortCollation</code> triple is present and the
+ </p>
+ <p>
+ When the <code>ldp:pageSortCollation</code> triple is present and the
<a title="page-ordering values">page-ordering values</a> are strings or simple literals
[[!sparql11-query]], the
resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
[[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the
specified collation.
- The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
- involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
+ </p>
+ </blockquote>
</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
</section> <!-- h2 -->
@@ -2003,7 +2073,7 @@
reviews, content, criticism and input in the creation of this specification:</p>
<p style="margin-left: 3em;">
- Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Gregory McFall, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
</p>
</section>
@@ -2018,6 +2088,10 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
+ <li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
+ <li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>
+ <li>2014-07-28 - Updates based on Sandro's email, excluding those on public comments list (JA) </li>
<li>2014-07-28 - Updates to address public review comment on must-not initiate paging (JA) </li>
<li>2014-07-28 - Updates to address public review comment on Prefer (JA) </li>
<li>2014-07-17 - Fixed minor spelling/grammar and validation problems (SS)</li>