Re: Call for consensus on hydra:filter (ISSUE-45)

Hi Thomas,

> __But__ I think be should take a step back and first decide whether it is a design goal of hydra to address querying and filtering in general.

Fair enough, or maybe to rephrase this: whether it belongs in the Hydra Core Vocabulary.
Because in addition to the core, there might be several extensions which go deeper into some aspects.

> The first question that
> popped in my head when I read your proposal is: "fine, and what about sorting?".

Sorting would for me something that needs an entirely different vocabulary,
because there are so many cases and variations. But that's my opinion.

However, I agree that you can say the same thing about filtering:
there are also many options for that.

One option could be that the Hydra Core Vocabulary contains the basics:
hydra:filter to do an exact AND search (more complex things: see other vocabulary).

A main argument here is that the current hydra:search is (purposely) too vague to be of any use:
the server has total liberty to decide how it will select items from a collection.
With hydra:filter, we would have one concrete implementation for a common case.
There are many other cases, but fixing one of them does not preclude others.

(Something similar _could_ be done for sorting, but that's a different discussion.)

> The thing is that the whole problem is complex and there are subtle bus nasty details to take car of:
> How to reflect data types like boolean (is "1", 1 true?) or how to deal with date-time formats?

For the exact matching case, these are described by hydra:variableRepresentation.
(It's different if you want this to work with partial date matches etc.)

> What about boolean concationation of filters? etc. etc.

That would definitely not belong in Core for me.

Best,

Ruben

Received on Friday, 30 October 2015 09:36:35 UTC