W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

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

From: Asbjørn Ulsberg <asbjorn@ulsberg.no>
Date: Mon, 9 Nov 2015 08:57:52 +0100
Message-ID: <CAEdRHi5ZB7NraHWkr=_tU3VBjRUMtgeXK+33T9P7wBZiddB3iQ@mail.gmail.com>
To: Thomas Hoppe <thomas.hoppe@n-fuse.de>
Cc: Hydra <public-hydra@w3.org>
2015-10-30 10:17 GMT+01:00 Thomas Hoppe <thomas.hoppe@n-fuse.de>:

> 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?
> What about boolean concationation of filters? etc. etc.
> There are efforst that already dealt with these issues or at least oarts of
> if, like OData [2]

I agree that Hydra shouldn't delve too deep (or at all) into this
area. If it does, it needs to feature-match the querying, ordering,
expansion and data type matching capabilities of OData, which I'd say
is way out of scope.

Perhaps more importantly, though, OData has this nailed down already.
We've used OData querying (or variants thereof) in applications for 4
years now and have found very few shortcomings. At least with .NET's
type system, the current specification solves just about any thinkable
problem we've had to throw at it. Beating this record is going to take
a lot of work and I just can't think of any good reasons why Hydra
should try to tackle this problem at all.

If Hydra needs a device to solve this problem, can't it just reference
OData v4.0 Query Options and be done with it?

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»
Received on Monday, 9 November 2015 07:58:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 November 2015 07:58:22 UTC