Re: Filters as views (ISSUE-45)

>> I had a chance to review your examples and more and more I'm into 
>> dropping
>> separate paging approach in favour of a more general solution.
>... meaning that your start to favor a views-based solution?
Indeed. I've been trying to support that for some time now.

>> I think that there should only be one such view in a response.
>How would you communicate to a client then that the response was not only 
>filtered, but that the server also decided to paginate it?
Well, considering that example I presented client can find it out in several 
ways: first/last/etc. links or that a view's template denotes a "special" 
property of hypothetical hydra:page.

>> Also I'm not sure about mixing both ViewTemplate and View on single 
>> `view` property.
>We can certainly split it into two properties but I'm not sure that would 
>buy us much. What advantages would you see?
I cannot say for Tomasz, but there is another way - we can leave a single 
'view' property, but the resource on the right hand side would be also a 
single one.

>> I fully support Tomasz' statement. We had these arguments with Ruben and 
>> by
>> seeing an example of how a mix of these two (three?) "views" looks like
>> makes the unified approach more solid.
>If more people find PartialCollectionView to specific, I'd be fine going 
>with just View for the time being.
>Please keep in mind however that it will make documentation of the 
>vocabulary more difficult (the totalItems property only applies is it is a 
>view of a collection; first/next/... only apply if the view is used in 
>pagination; ...)
I'm still having problem with reckoning those two as separate views - this 
is a single view, only driven by more than one factor (paging and 
filtering).

>> Logically, the collection has many views which can overlap. Ultimately,
>> union of all views builds a collection. In the examples my feeling is 
>> that
>> paging and filtered views are disjoined, which obviously is untrue.
>> Something in form of the one below seems more elegant and natural:
>>
>> GET /markus/friends?first=Ruben
>> {
>>   "@id": "/markus/friends",
>>   "@type": "Collection",
>>   "totalItems": 578
>>   "member": [...],
>>   "view": [{
>>       "@id": "/markus/friends?first=Ruben&page=1",
>>       "totalItems": 10,
>>       "first": "/markus/friends?first=Ruben&page=1",
>>       "next": "/markus/friends?first=Ruben&page=2",
>>       "last": "/markus/friends?first=Ruben&page=2"
>>       "template": "/markus/friends{?first,last,page}",
>>       "mapping": [
>>         { "variable": "first", "property": "schema:givenName" },
>>         { "variable": "last", "property": "schema:familyName" },
>>         { "variable": "page", "property": "hydra:page" }
>I already expected that you'd somehow sneak this into this discussion :-) 
>But please, let's try to not conflate these two discussions.

As I wrote before - I acknowledge these two (or three including sorting) to 
be complementar features, thus I don't feel like those should be considered 
separately.

>The server decides to paginate here, not the client. I used page=x as URL 
>parameter for the sake of simplicity but I could (and probably should) have 
>also used an arbitrary token which the client wouldn't be able to construct 
>easily.

Well, I'm not sure why client shouldn't be allowed to construct these kind 
of controls on it's own.
Indeed, it's up to the server to paginate or not and to tell the client on 
how to do it or not.
The paging example you provided disallows client to change both page and 
filter specification at the same time. While changing the filters themselves 
and page simultanously would lead to i.e. 404s, changing i.e. sort direction 
(which is yet not covered by Hydra) doesn't change anything in filtering and 
paging, but creates a different view.

>>       ],
>>       "filterSpecification": {
>>         "operator": "AND",
>>         "operands": [
>>           { "variable": "first" },
>>           { "variable": "last" }
>>         ]
>>       }}}
>> I dropped typing on purpose. I also dropped the "totalItems": 15 
>> collection
>> as I'm not quite sure how should I "acknowledge" it.
>Right, and that's a major limitation. How would a client know that only 15 
>members matched the criteria?
>In quite a few use cases it is important to know beforehand how many items 
>match.
>Triple Pattern Fragments is one of them by the way. So omitting that 
>information is a no-go I'd say.
Ok, now I understand it's purpose.

>> Lastly, I think that the filterSpecification will have to be discussed
>> in detail separately and must not hold us back from agreeing upon the
>> general view structure. Is it possible the we leave the filters a bit
>> underspecified and resolve views first?

We agreed on views already back in October [1-3]. This discussion is about 
ISSUE-45 [4], i.e., filters. That being said, I'm happy to re-open ISSUE-42 
if new insights are presented. Your statement that PartialCollectionView 
might be too specific is certainly a first step in that direction.

>Unfortunately, no one commented on filterSpecification so far. I would love 
>to hear your thoughts about that.
Let me be the first though. It remind's me a bit of a SPIN constructs, but 
this isn't a surprise - those are binary operators. Only thing that concerns 
me here is the operand's precedence. It might be useful to enforce a 
specific order of the operands, i.e. from optimization point of view. It's 
sometimes worth of putting a specific operand first before others in the 
"AND" chain so the whole filter fails soon enough to prevent it from 
deep-diving further.

Received on Monday, 8 February 2016 22:19:23 UTC