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

Hi Markus

I was refering more to the idea of a base ReST resource and it's 
parametrized views, not the LDP spec details.
Indeed base collection resource IRI with query string parameters will craft 
a separate RDF statements in the payload, but still these wouldn't be 
dereferencable separately from their base resource and logically have no 
meaning.

>> 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.
OK. The server provides the data to match a view configuration, but that 
view configuration is provided by the client. I think that server should 
equip client with tools, but its the client who knows what he wants to 
receive.

>... 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
>      ]
>   ]
Finally :). You've reached a point where I'm already with my URSA tool. I 
had to use two "special" predicate mappings to craft a link to a 
limit-offset (I think it's more generic than page/page size). These are 
values that cannot be mapped to any of the resources in the context and 
usually are provided by i.e. human.
I'm more keen to drop completely notion of a collection and stick to a 
partialViewTemplate name. Paging is one of the possible view configuration 
and it can be either standalone or in conjuction with other features like 
sorting or filtering mentioned or can be completetly omitted.

>> - 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?
See above. I think we'll have even more discussion on how to provide 
information on how client would like the view to be sorted. But thats 
another story.

>> - 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.
True

>Cool. Let us know as soon as you have a demo or something ready that we
>could take a look at.
Sure. Other thing is I currently have no access to publicaly available host 
with .net. I'll try to figure it out.

Best

Karol

Received on Monday, 12 October 2015 21:01:03 UTC