Re: Filters as views (ISSUE-45)

February 9 2016 11:15 AM, "Ruben Verborgh" <ruben.verborgh@ugent.be> wrote: 
> Hi Markus,
> 
>> I slightly refined it and wrote down an
>> exemplary interaction flow at
>> 
>> https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow
> 
> Thanks for setting this up!
> 
> This proposal delivers what we needed for a long time,
> and I will support it once its remaining issues have been resolved.
> Since this proposal makes me almost happy,
> I will not be submitting an alternate one.
> This is the right direction for me.
> 
> Below is my feedback.
> Summarizing, my main concerns are the lack of definitions,
> the double use of view, and the description of view members.
> 
> – These examples finally cover the needs of AND-filtering.
> 
> – In general, we need definitions of:
> – collection
> – view
> – viewtemplate
> It's important to know what exactly we are talking about.
> In particular, we need to know whether a view is a collection,
> and from the reuse of properties, this seems to be the case here.
> 
> – Maybe the examples can be enhanced a bit with plaintext,
> to understand what exactly the intended semantics are.
> 
> – In GET /markus/friends, I don't understand view/ViewTemplate.
> What is this supposed to express?
> "The friends have a view that is a template that…"?
> I see conceptually what is going on,
> but I have trouble linking this with the view predicate.
> 
> – What is the domain of filterSpecification?
> Is it something like "Expression"?
> If so, does "operands" also take an expression?
> (I.e., can we compose recursively?)
> 
> – Will the operators receive IRIs?
> I.e., can I assume that "AND" is hydra:AND,
> or was it intended as the string "AND"?
> 
> – Is there a default semantics for viewtemplate? (AND?)
> 
> – With regard to naming, we still seem to have a "filter" concept.
> We could/should get rid of this by renaming "filterSpecification".

I don't want to deprecate your effort to raise the points above, but this is precisely why I asked in my previous email to focus on general View/ViewTemplate semantics and leave filters for later. IMO we will be fine with unspecified filters' semantics. It is how traditional forms work on HTML pages anyway.

> 
> – In GET /markus/friends?first=Ruben,
> I think the view flaw really becomes apparent.
> The thing seems to have two views. That's not right.
> It has one view (the page you're currently looking at),
> and one control (find other friends).
> 
> – GET /markus/friends?first=Ruben does not explicitly say
> that Ruben is part of the view.
> This might or might not be necessary.
> I would argue it is necessary for transparency:
> if the thing is attached to the view,
> clients can just read its elements,
> without having to care whether something is a collection or a view.
> 
> – With regard to the above, an alternative way
> to express GET /markus/friends?first=Ruben
> would be to make "/markus/friends?first=Ruben" the "main" resource,
> to express Ruben as a member of that,
> and relate the resource to its parent. ("viewOf"?)
> Now, the "main" resource is the collection the view belongs to.
> Same with paging.

I don't think Hydra should be too opinionated about that. /markus/friends?first=Ruben and /markus/friends are perfectly fine to be resources in their own right. The decision should be up to the data publisher/API author and not to us. What is important is the hypermedia control, which drives creation of derived resource, which we have in the form of ViewTemplate.

> 
> – GET /markus/friends: the "totalItems 10" correctly expresses
> the number of items on the current page.
> It does, however, not say anything about the other pages.
> This might or might not be desired.

Hold on, I'm confused. Doesn't View's totalItems mean that the number of items of filtered, but unpaged collection? Why would it express the number of items on the current page? This can be determined by counting the members.

> 
> – PartialCollectionView definitely needs to become View.
> 
> Best,
> 
> Ruben

Received on Tuesday, 9 February 2016 11:42:48 UTC