RE: Pagination - let's finalize the collection design (ISSUE-42)

On 12 Okt 2015 at 08:56, karol.szczepanski@gmail.com wrote:
> I fully support view approach. I suggested view-like approach in
> Februrary
> (http://lists.w3.org/Archives/Public/public-hydra/2015Feb/0009.html),
> similar document-like approach appeared before several times as well.

Sorry, I didn't realize at all that you were suggesting something similar
back then. That being said, I don't think LDP is similar to this. If you
look at example 6 in the spec [1] you'll see that the view isn't made
explicit but their trick is to move that information to Link headers to
"hide" them from the client:

  GET /customer-relations?page1 HTTP/1.1

  HTTP/1.1 200 OK
  Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
        <http://www.w3.org/ns/ldp#Page>; rel="type"
  Link: <http://example.org/customer-relations?p=2>; rel="next"
  Link: <http://example.org/customer-relations>; rel="canonical";
etag="customer-relations-v1"

  <>
     a o:CustomerRelations;
     dcterms:title "The customer information for Example Co.";
     o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>.

If you would convert the link headers to triples, they would say this:

  <>
     iana:type http://www.w3.org/ns/ldp#Resource
     iana:type http://www.w3.org/ns/ldp#Page
     iana:next http://example.org/customer-relations?p=2

So the collection is both a collection and a Page at the same time. I don't
find this very elegant.


> Still, your example has still several flaws and I think we'll end up
> with a conclusion that while served indeed provides a view, but the view
> is crafted by the client.

Sorry, I have troubles to parse this sentence. Could you please rephrase it.


> We'll end up with very basic but still
> covering 95% of use cases "query like" hydra platform that will allow
> client to do simple operations we all know from applications we develop:
> - show first page of the collection - currently covered
> - show numbered pager - currently client wouldn't know how many pages
there
> are

We ignored hydra:itemsPerPage and hydra:totalItems in all our recent
discussions of pagination. That doesn't mean we will remove them. I think
they are quite useful and AFAICT there's nothing in the proposed design that
would prevent their usage.

> - show next/prev - currently covered
> - show next/prev bucket of pages - currently not covered

That's supported. You can include details of other pages in the response as
well:

   /an-issue/comments view /an-issue/comments?page=3
   /an-issue/comments?page=3 next /an-issue/comments?page=4
   /an-issue/comments?page=4 next /an-issue/comments?page=5
   /an-issue/comments?page=6 next /an-issue/comments?page=7

... and so on. I think, however, that you had something else in mind.. and I
think we will address when we agreed on the basics. We can augment the
collection with hypermedia controls that allow clients to address specific
views. In spirit it would look somewhat like this (in practice, it would
likely look quite a bit different): 

   /an-issue/comments partialCollectionViewTemplate [
      template /an-issue/comments?page{page}
      mapping [
         variable page
         property xxxx
         required true
         minValue 0
         maxValue 100
      ]
   ]


> - provide sorting details - currently client doesn't know anything about
> that - it is given some resources in unspecified order

Correct. We will also address that separately. I don't think anything in the
proposed design prevents that to be added easily. Or does it?


> - provide basic filtering details - freetextQuery is somehow solution
here,
> but I don't see it anyway connected to the paging and collection

That's I think one of the nice things about this proposal. It would nicely
generalize to such use cases. A query on a collection would result in a
FilteredCollectionView (PartialCollectionView would be fine as well I
guess). Telling the client how to get from a collection to such a view is a
very important but a different discussion. Let's first focus on how we
represent views on collections.

 
> These should come from the client with server defaults if nothing is
> explicitly expressed.
> 
> I've started a proof of concept of a angularJS application that would user
> hydra API Documentation provided by my URSA tool to build a generic
> on-the-fly generated views and will provide feedback on issues
experienced.
> This should give a hint of what might be needed so developers will know
how
> to proceed with that.

Cool. Let us know as soon as you have a demo or something ready that we
could take a look at.


Cheers,
Markus


[1] http://www.w3.org/TR/ldp-paging/#ldpp-ex-paging-303


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 12 October 2015 19:28:37 UTC