--- a/ldp-paging.html Sun Jul 13 11:33:28 2014 -0400
+++ b/ldp-paging.html Tue Jul 15 08:53:46 2014 -0400
@@ -4,7 +4,7 @@
DONE: http://www.w3.org/2013/meeting/ldp/2014-04-15#resolution_7 : At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.
DONE: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 3: spec sandro's paging proposal
DONE: http://www.w3.org/2012/ldp/track/issues/94 -> http://www.w3.org/2013/meeting/ldp/2014-05-12#resolution_3 2014-04-17 resolution 3: spec sandro's paging proposal
- TODO: STARTED: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 4: page size hint
+ DONE: STARTED: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 4: page size hint
DONE: http://www.w3.org/2013/meeting/ldp/2014-04-17 resolution 5: contains+member triple always on same page
DONE: http://www.w3.org/2013/meeting/ldp/2014-05-12 resolution 4: ordering undefined when paging non-LDPC LDPRs
@@ -278,12 +278,16 @@
<p>
</p>
- <div class="atrisk" id="atrisk-paging"><p class="atrisktext">UNDER CONSTRUCTION</p>
+ <div class="atrisk" id="atrisk-paging"><p class="atrisktext">Ready for LC?</p>
+ Working group is currently assessing this draft's readiness to be issued as a Last Call WD.
+ Comments are solicited on the WG mailing list the week of July 14, 2014, and a vote to publish
+ (or a list of issues that need to be fixed prior to publication, or both)
+ is anticipated at the July 21 meeting.
</div>
</section>
<section class="informative" id="intro">
-<!-- TODO: Move bulk of paging intro here - it's not rocket science -->
+
<h1>Introduction</h1>
<p>
This specification provides a widely re-usable pattern to make the state of a large <a title="Paged resource">paged HTTP resource</a>
@@ -298,11 +302,11 @@
When a client attempts to retrieve a <a>paged resource</a>, the server either redirects the client to
a "first page" <a title="In-sequence page resource">resource</a> or provides the
representation of the "first page" <a title="In-sequence page resource">resource</a> in its response,
- depending on the client's request preferences. <a title="LDP Paging client">Paging-aware clients</a>
- can save the latency of making a second request to retrieve the first page when the server supports this,
- in addition to knowing how to combine pages.
- In either case, the response containing the first page's representation
- includes a link to another page in the sequence, as do all other non-terminal pages.
+ depending on the client's request preferences and the server's capabilities.
+ The response
+ includes links to other page(s) in the sequence, as do subsequent pages.
+ <a title="LDP Paging client">Paging-aware clients</a>
+ know how to combine pages of an LDP-RS, and possibly (via other specifications) other LDPRs.
LDP Paging defines a mechanism by which clients can learn that the <a>paged resource</a> has been changed
so that they can, for example, abandon a page traversal as early as possible.
A detailed example of paging is provided in <a href="#ldpp-ex-mx" class="sectionRef"></a>.
@@ -384,7 +388,7 @@
a subset of the triples in <var>P</var>.
LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>,
but does not specify how clients combine
- their representations. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+ their representations. See <a href="#ldpr" class="sectionRef"></a> for additional details.
</p>
For readers
familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
@@ -808,7 +812,9 @@
In this example, there are only two customers provided in the
second page.
</p>
- <!-- TODO: show it both ways; if a competing change hit the container, or not -->
+ <!-- DONE: show it both ways; if a competing change hit the container, or not.
+ 6.2.2.7's non-normative note covers this case.
+ -->
<ul>
<li>
The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
@@ -837,7 +843,7 @@
</section>
<section id="ldpp-ex-paging-2nn">
-<h2>Optimized paging flow</h2>
+<h2>Removing redirection latency when paging</h2>
<p>
It is inconvenient that the <a href="#ldpp-ex-paging-303"><code>303 See Other</code> approach</a>
@@ -1061,7 +1067,7 @@
Any <a>in-sequence page resource</a>'s response message, including the <a title="first page link">first page</a> and the <a title="last page link">last page</a>,
might also have the following links:
<pre class="example">
-Link: <>; rel='first'
+Link: <http://example.org/customer-relations?page1>; rel='first'
Link: <http://example.org/customer-relations?p=2>; rel='last'
</pre>
</li>
@@ -1083,19 +1089,12 @@
<h1>Linked Data Platform Paging Clients</h1>
<p>All of the following are conformance rules for <a title="LDP Paging client">LDP Paging Clients</a>.
</p>
-<section><h2>General</h2>
+<section><h2>General requirements</h2>
<section id="ldpp-client-advertise"><h2 class="normal"><a title="LDP Paging client">LDP Paging clients</a> MUST
<a href="#ldpp-hints">advertise their ability to support LDP Paging</a> on all retrieval requests that normally result in
a response containing a representation.
</h2>
- <div class="ldp-issue-pending" id="what-the-pagesize-required"><p class="ldp-issue-title">For Discussion</p>
- <p>
- Given that servers Must Not initiate paging unless the client acks that it understands LDP paging,
- e.g. by sending a Prefer: pagesize header, do we want to add a Must on clients to send that header?
- Some support for doing so on the mailing list week of 7 July 2014 resulted in <a href="#ldpp-client-advertise" class="sectionRef">this strawman</a>.
- </p>
- </div>
</section>
<section id="ldpp-client-traversal"><h2 class="normal"><a title="LDP Paging client">LDP Paging clients</a> MUST
@@ -1154,15 +1153,6 @@
<li>It communicates the client's maximum desired size for a response representation</li>
</ul>
</p>
- <blockquote>
- <em>Non-normative note</em>: LDP server implementers should carefully consider the effects of these
- preferences on caching, as described in section 2 of [[!RFC7240]].
- </blockquote>
- <blockquote>
- <em>Non-normative note</em>: [[!RFC7240]] recommends that server implementers include a
- <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
- behavior with respect to honoring hints from the response content.
- </blockquote>
<p>
LDP Paging defines <code>page-size</code> as a new parameter on the existing
@@ -1188,10 +1178,6 @@
<code>token</code> is as defined in [[!RFC7230]].
The generic preference BNF [[!RFC7240]] allows either a quoted string or a token as the value of a
preference parameter; LDP Paging assigns a meaning to the value only when it is a quoted string.
- <a title="LDP Paging server">LDP Paging servers</a> MAY
- ignore a page size of zero, or unrecognized <code>units</code>,
- and process the request as if no maximum desired size was specified; in the latter case the server
- can select whatever page size it deems appropriate, or choose not to page the resource at all.
</p>
</blockquote>
</p>
@@ -1209,31 +1195,23 @@
<section id="ldpr">
<h1>Linked Data Platform Resources</h1>
-<section class="informative" id="ldpr-informative">
-<h2>Introduction</h2>
- <div class="ldp-issue-closed"><p class="ldp-issue-title">Editorial note</p>
- <p>
- There is more duplication between this content (its original home) and other sections
- (<a href="#intro" class="sectionRef"></a>, <a href="#ldpp-ex-mx" class="sectionRef"></a>) than we'd prefer.
- It's on-going work to reduce the duplication.
- </p>
- </div>
+<section class="informative" id="ldpr-PagingIntro">
+
+<h3>Paging considerations</h3>
+
<p>
- Some LDPRs are too large to reasonably transmit a representation in a
- single HTTP response.
- To address this problem, <a title="LDP Paging server">LDP Paging servers</a> can support a technique called Paging.
- When a client retrieves such a resource, the server redirects the client to a "first page" resource, and includes in its response
- a link to the next part of the resource's state, all at URLs of the server's choosing.
- The representation of <a title="In-sequence page resource">each page of an LDPR</a>
- is typically a subset of the <a title="Paged resource">paged resource</a>.
- Any LDPR can be paged, but certain aspects of paging like ordering are only well-defined for LDP-RS's or LDPCs.
+ As <a href="#intro">described</a> <a href="#ldpp-ex-mx">previously</a>,
+ paging logically breaks up a <a>paged resource</a>
+ into a list of <a title="In-sequence page resource">in-sequence page resources</a> (pages) whose representations the client can retrieve, and serves each
+ page with links to other <a title="In-sequence page resource">pages in the sequence</a>.
+ Clients inspect each response to see if additional pages
+ are available; paging does not affect the choice of HTTP status code.
+ Clients generally have no insight into the allocation of information to pages,
+ although in <a href="#ldpc">some cases currently defined only for LDPCs</a> the server can expose its
+ algorithm.
</p>
<p>
- Logically, paging breaks up the <a>paged resource</a>
- into a list of <a title="In-sequence page resource">in-sequence page resources</a> (chunks) whose representations the client can retrieve.
- A server can offer links that support forward and/or backward traversal of
- the pages, but it has to offer at least one.
- Likewise, some clients will be interested in knowing whether or not competing requests altered the
+ Some clients will be interested in knowing whether or not competing requests altered the
<a>paged resource</a> while the client was retrieving pages, since LDP paging does not guarantee
that those alterations were reflected in any <a>in-sequence page resource</a> received by the client.
Regardless of the server implementation, LDP only guarantees that while traversing a series of pages that
@@ -1242,54 +1220,21 @@
specifically, clients can observe
non-repeatable reads [[NON-REPEATABLE-READS]] while traversing pages served by
<a title="LDP Paging server">LDP Paging servers</a>.
- LDP Paging does guarantee, however, that any information in the LDPR continuously present (neither added nor deleted) in the
+ LDP Paging does <a href="#ldpr-guarantee-show-unchanged">guarantee</a>, however, that any information in the LDPR continuously present (neither added nor deleted) in the
<a title="Paged resource">paged resource</a> across the entire period of time when the client is retrieving pages will
be present in at least one <a>in-sequence page resource</a>.
- LDP Paging defines a mechanism for informing clients that the <a>paged resource</a> has been changed so that they can, for example,
- abandon a page traversal as early as possible.
</p>
<p>
- A list of <a title="In-sequence page resource">in-sequence page resources</a> is inherently ordered by the links
- that a <a>LDP Paging server</a> exposes on any <a>paged resource</a>. LDP Paging defines
- a vocabulary for communicating the ordering algorithm used by the <a>LDP Paging server</a>
- only in the case where the <a>paged resource</a> is an LDPC; other specifications or future
- versions of LDP Paging might define ordering in other cases.
- </p>
-</section>
-
-<section id="ldpr-Paging">
-<h2>Paging</h2>
-
-<section class="informative" id="ldpr-PagingIntro">
-
-<h3>Introduction</h3>
- <div class="ldp-issue-closed"><p class="ldp-issue-title">Editorial note</p>
- <p>
- There is more duplication between this content (its original home) and other sections
- (<a href="#intro" class="sectionRef"></a>, <a href="#ldpp-ex-mx" class="sectionRef"></a>) than we'd prefer.
- It's on-going work to reduce the duplication.
- </p>
- </div>
- <p>
- <a title="LDP Paging server">LDP Paging servers</a> may respond to requests for a
- resource by redirecting to the first page of the resource and, with that, returning
- a <a>next page link</a> containing the URL for the next page.
- Clients inspect each response for the link to see if additional pages
- are available; paging does not affect the choice of HTTP status code.
- Note that paging provides a
- <a href="#ldpr-guarantee-show-unchanged">weak guarantee of completeness</a>: if and only if it is the case
- that no changes to the <a>paged resource</a> are made while
- a client retrieves every <a>in-sequence page resource</a> logically comprising it,
- then the client will expect to have a complete picture of the <a>paged resource</a>
- at a point in time. Since LDP Paging ensures that clients have a way to find
- out when the <a>paged resource</a> has changed, this is a stronger guarantee
+ LDP Paging defines a mechanism by which <a href="#ldpr-notify-changes">clients can detect that the paged resource has been changed</a> so that they can, for example,
+ abandon a page traversal as early as possible.
+ This provides a stronger guarantee in certain cases
than the one described for paged feeds [[RFC5005]], but it does require the client
to detect when the condition holds.
Paging <i>does not guarantee</i> that it will ever be possible to successfully
retrieve all the <a>in-sequence page resource</a>s without the <a>paged resource</a>
being added to or changed, so clients requiring such a guarantee
may not find all <a>paged resource</a>s usable in practice.
- A detailed example is provided in <a href="#ldpp-ex-mx" class="sectionRef"></a>.
+ A detailed example was provided in <a href="#ldpp-ex-mx" class="sectionRef"></a>.
See <a href="#ldpr-impl" class="sectionRef"></a> for server implementation considerations.
</p>
</section>
@@ -1328,6 +1273,22 @@
<a href="#ldpp-hints">the largest page size</a>
the client is interested in processing,
to influence the amount of data returned in representations.
+ <blockquote>
+ <em>Non-normative note</em>: LDP server implementers should carefully consider the effects of these
+ preferences on caching, as described in section 2 of [[!RFC7240]].
+ </blockquote>
+ <blockquote>
+ <em>Non-normative note</em>: [[!RFC7240]] recommends that server implementers include a
+ <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
+ behavior with respect to honoring hints from the response content.
+ </blockquote>
+ </h2></section>
+
+ <section id="ldpp-prefer-unrecognized"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> MAY
+ ignore a <a href="#ldpp-hints">page size</a> of zero, or unrecognized <a href="#ldpp-hints"><code>units</code></a>,
+ and process the request as if no maximum desired size was specified; in the latter case the server
+ can select whatever page size it deems appropriate, or choose not to page the resource at all.
</h2></section>
<div class="atrisk" id="atrisk-2NN"><p class="atrisktext">Feature At Risk</p>
@@ -1396,6 +1357,7 @@
</blockquote>
</section>
+ <!--
<div class="ldp-issue-pending" id="question-link-relation"><p class="ldp-issue-title">Feedback requested on the link relation type used below</p>
<p>Background: likely suspects from the <a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA link relation registry</a> that the editors examined:</p>
<ul>
@@ -1428,6 +1390,7 @@
</p></li>
</ul>
</div>
+ -->
<section id="ldpr-notify-changes"><h2 class="normal">
<a title="LDP Paging server">LDP Paging servers</a> MUST
@@ -1531,13 +1494,12 @@
This is one mechanism by which clients know that the resource is one of a sequence of pages.
</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
- <div class="ldp-issue-pending" id="what-the-new-container"><p class="ldp-issue-title">For Discussion</p>
- <p>
- Need to clarify expected behavior(s).
- Some support for doing so on the mailing list week of 7 July 2014.
- </p>
- <p>
- Strawman based on Sandro's response: add to the normative requirement below:
+ <section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> MUST NOT
+ initiate paging unless the client has indicated it understands paging.
+ The only standard means defined by LDP paging for a client to signal a server that the client
+ understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+ other implementation-specific means could also be used.
<blockquote>
<em>Non-normative note:</em>
<a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
@@ -1551,52 +1513,41 @@
status code concludes that it now has the <em>entire</em> representation of the paged resource's state (instead
of only having a representation of the subset assigned to the first page).
</blockquote>
- </p>
- </div>
-
- <section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> MUST NOT
- initiate paging unless the client has indicated it understands paging.
- The only standard means defined by LDP paging for a client to signal a server that the client
- understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
- other implementation-specific means could also be used.
</h2></section>
</section>
-</section> <!-- h2 -->
-
-
</section> <!-- h1 -->
<section id="ldpc">
<h1>Linked Data Platform Containers</h1>
+<section id="ldpc-general">
+<h2>Requirements when paging LDP Containers</h2>
+
+ <section id="ldpc-onsamepage"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> MUST
+ ensure that the <a title="membership triples">membership triple</a> and
+ <a title="containment triples">containment triple</a> for each member are part of the
+ same <a>in-sequence page resource</a>, whenever both triples are present in the page sequence
+ for a <a title="paged resource">paged LDPC</a>.
+ </h2></section>
+
+</section>
+
<section class="informative" id="ldpc-informative">
-<h2>Introduction</h2>
- <p>Many HTTP applications and sites have organizing
- concepts that partition the overall space of resources into smaller
- containers. Blog posts are grouped into blogs, wiki pages are grouped
- into wikis, and products are grouped into catalogs. Each resource
- created in the application or site is created within an instance of
- one of these container-like entities, and users can list the existing
- artifacts within one. LDP Paging Containers answer some basic questions, which
- are:</p>
- <ol>
- <li>How is the order of the container entries expressed?</li>
- </ol>
+<h2>Ordering of container members across pages</h2>
<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
<p>
There are many cases where an ordering of the members of a
- container is important. LDP does not provide any particular support
+ container is important. [[!LDP]] does not provide any particular support
for server ordering of members in containers, because any client can
order the members in any way it chooses based on the value of any
available property of the members. In the example below, the value of
the <code>o:value</code> predicate is present for each
member, so the client can easily order the members according to the
- value of that property. In this way, LDP avoids the use of RDF
- constructs like Seq and List for expressing order.
+ value of that property.
</p>
<p>
Order becomes more important when containers are
@@ -1606,6 +1557,8 @@
In cases where ordering is important, an <a>LDP Paging server</a> exposes all the
members on a page with the proper sort order with relation to all
members on the next and previous pages.
+ <em>This says nothing about the ordering of members within any
+ <a title="In-sequence page resource">single page</a>.</em>
When the sort is ascending, all the members on a current page have a
sort order no lower than all members on the previous page and
sort order no higher than all the members on the next page;
@@ -1621,7 +1574,8 @@
<code>ldp:containerSortPredicate</code>, and
optionally a <code>ldp:containerSortCollation</code>.
</p>
- <p>Here is an example asset container described in [[LDP]] section 5.1,
+ <p>
+ Here is an example asset container described in [[LDP]] section 5.1,
with the ordering of the assets asserted:</p>
<em>Request</em>
@@ -1635,18 +1589,19 @@
</p>
<em>Response:</em>
-<pre class="example" id="ldpc-ex-ordering">
+<pre class="example" id="ldpc-ex-ordering-nopaging">
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ff291112"
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/
<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/netWorth/nw1/assetContainer/>
+# @base <http://example.org/netWorth/nw1/assetContainer/> .
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@@ -1656,11 +1611,10 @@
dcterms:title "The assets of JohnZSmith";
ldp:membershipResource <http://example.org/netWorth/nw1>;
ldp:hasMemberRelation o:asset;
- ldp:insertedContentRelation ldp:MemberSubject.
+ ldp:insertedContentRelation ldp:MemberSubject;
+ ldp:contains <a1>, <a2>, <a3>.
<?firstPage>
- a ldp:Page;
- ldp:pageOf <>;
ldp:containerSortCriteria (<#SortValueAscending>).
<#SortValueAscending>
@@ -1677,53 +1631,135 @@
o:value 100.00 .
<a2>
a o:Cash;
- o:value 50.00 .
+ o:value 505.00 .
<a3>
a o:RealEstateHolding;
- o:value 300000 .
+ o:value 100.00 .
</pre>
- <p>
- As you can see by the addition of the <code>ldp:ContainerSortCriteria</code>
- predicate, the <code>o:value</code> predicate is used
- to order the page members in ascending order. It is up to the domain model
- and server to determine the appropriate predicate to indicate the
- resource’s order within a page, and up to the client receiving this
- representation to use that order in whatever way is appropriate, for
- example to sort the data prior to presentation on a user interface. Also
- as it is possible for a container to have as its members other containers,
- the ordering approach doesn't change as containers themselves are LDPRs and the
- properties from the domain model can be leveraged for the sort criteria.
- </p>
- </section><!-- Was 5.1.2 / #ldpc-ordering -->
-</section>
+ <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 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.
+ </p>
+
+ <p>
+ Had the server responded instead with a redirect to a first page,
+ whose representation was (after following a redirect):
+ </p>
-<section id="ldpc-general">
-<h2>General</h2>
- <p>The Linked Data Platform does not define how clients
- discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
+<em>Response:</em>
+<pre class="example" id="ldpc-ex-ordering-page1">
+HTTP/1.1 200 OK
+Content-Type: text/turtle
+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/?p=2>; rel='next'
+Link: <http://example.org/netWorth/nw1/assetContainer/>; rel='canonical'; etag="v1"
+Allow: GET,OPTIONS,HEAD
+Transfer-Encoding: chunked
- <div class="ldp-issue-pending" id="what-the-new-container"><p class="ldp-issue-title">For Discussion</p>
- <p>Are we attempting to define a new type of container here? If not, should delete the clause.
- Some support for doing so on the mailing list week of 7 July 2014.
- </p>
- </div>
-
- <section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Paging Container MUST also be
- a conforming Linked Data Platform Container.
- </h2></section>
+# 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 <http://example.org/netWorth/nw1/assetContainer/> .
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<>
+ a ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ 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>.
+
+<a1>
+ a o:Stock;
+ o:value 100.00 .
+</pre>
- <section id="ldpc-onsamepage"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> MUST
- ensure that the <a title="membership triples">membership triple</a> and
- <a title="containment triples">containment triple</a> for each member are part of the
- same <a>in-sequence page resource</a>, whenever both triples are present in the page sequence
- for a <a title="paged resource">paged LDPC</a>.
- </h2></section>
+ <p>
+ Then the client would be guaranteed that the values of <code>o:value</code> 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>
+ <p>
+ When the client retrieves the second page by following the <code>rel='next'</code> link,
+ its representation might be:
+ </p>
+
+<em>Response:</em>
+<pre class="example" id="ldpc-ex-ordering-page2">
+HTTP/1.1 200 OK
+Content-Type: text/turtle
+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/>; rel='canonical'; etag="v1"
+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 <http://example.org/netWorth/nw1/assetContainer/> .
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<a2>
+ a o:Cash;
+ o:value 505.00 .
+<a3>
+ a o:RealEstateHolding;
+ o:value 100.00 .
+</pre>
-</section>
+ <p>
+ 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
+ sort criterion</em>, illustrating that this criterion applies only to the
+ sorting of "assigning members to pages", not
+ to the ordering within any single page's representation.
+ Typically those representations are generated by libraries like Jena,
+ whose serializers do not provide ordering of this variety.
+ </p>
+ <p>
+ It is up to the domain model
+ and server to determine the appropriate predicate to indicate the
+ resource’s order within a page (or globally), and up to the client receiving this
+ representation to use that order in whatever way is appropriate to meet its needs, for
+ example to sort the data prior to presentation on a user interface. Also,
+ as it is possible for a container to have as its members other containers,
+ the ordering approach doesn't change as containers themselves are LDPRs and the
+ properties from the domain model can be leveraged for the sort criteria.
+ </p>
+ </section><!-- Was 5.1.2 / #ldpc-ordering -->
+</section> <!-- containers . intro -->
<section id="ldpc-HTTP_GET">
-<h2>HTTP GET</h2>
+<h2>HTTP GET requirements for member ordering across pages</h2>
<section id="ldpc-sortcriteriaobj"><h2 class="normal">
<a title="LDP Paging server">LDP Paging servers</a> MAY
@@ -1837,7 +1873,7 @@
</p>
<p> LDP uses <code>209 Related Content</code> to provide clients with the
- <a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
+ <a href="#ldpr">first page of a large resource</a>, but it can also be used in
other common situations. Linked Data clients could benefit by avoiding the latency
of additional requests when the target resource is a concept resource (one without any
representation capable of transmission over HTTP), and general HTTP clients would
@@ -1962,6 +1998,7 @@
<!-- <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-15 - Final updates hopefully before LC2 draft issued (JA) </li>
<li>2014-07-09 - Fix Ashok's emailed comments (JA) </li>
<li>2014-07-09 - Clean up clients chapter, references, non/normative section listing in conformance, kitchen sink (JA) </li>
<li>2014-07-09 - Move paging example into "intro" chapter 4 (JA) </li>