Re: Filters as views (ISSUE-45)

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

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

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

– PartialCollectionView definitely needs to become View.

Best,

Ruben

Received on Tuesday, 9 February 2016 10:14:48 UTC