RE: Filtering collections etc. - taking a step back (ISSUE-45)

On 12 Apr 2016 at 00:07, Ruben Verborgh wrote:
> HI Markus,
> 
>>  - a description of why a client would want to use the IRI template and
> 
> Does "why" mean what the intended result will be?

Yes, it should describe the expected effects of executing the operation.


>> 7         the expected response will be a CollectionView
> 
> I think something important has been forgotten:
>      8 that is filtered in a so and so way
> All the rest, we can already do today.

I captured that as part of (6)


> (Not saying that we should describe all possible kinds of filters,
>  we're not going for a Turing-complete language here.)
>  
>> The trickiest part is definitely (6)
> 
> Ah no. 6 by itself is easy, just describing the parameters.
> It's describing the effect of those parameters that's tricky (my 8).

Sorry if this wasn't clear. I hoped the second part of the following
paragraph made it clear that describing the purpose of the parameters makes
it tricky:

  The trickiest part is definitely (6) -- at least if we want to make it
  machine-understandable. Think of something like "max price". For a human
  that is immediately clear. A machine would need to know that only
collection
  members whose price is smaller than max price would be returned. The same
  applies to the combination of parameters.

Are you saying to split this into two items? One for the description of the
constraints/validation of the parameters (there are 3 parameters, one is
required, two need to be positive integers) and one for the purpose of the
parameters? I tried to not get lost in implementation details in my
high-level description of how I see this.


>> Or we could define a few more specialized operation types (3) that
>> kind of hardcode the behavior for common use cases (example: a
>> specialization of "filter" that is defined as "filter the collection by
>> equality-checking the specified parameters to the corresponding
properties
>> of each collection member; multiple parameters are combined with AND").
> 
> That's still an easy an acceptable way out.
> hydra:filter as it was originally intended.
> 
> We should just make it possible
> to create extensions (not core) that
> allow to define predicates like hydra:filter.

Yep, that's my current thinking.


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 12 April 2016 07:22:37 UTC