Re: Filters as views (ISSUE-45)

Hi

>> In my suggestion
>>
>> "urlSyntax": "tpf url syntax uri"
>>
>> was not supposed to say it is a tpf api, only that the URI syntax is the 
>> one described by tpf.
>I understand—however, if that URI would indeed be specific to the TPF API, 
>then it would effectively be a “magic constant” and we might as well just 
>simply say “it's a TPF API”. When >describing APIs, one such magic constant 
>is enough to break access for any client that is not specifically 
>programmed for an API.

Not necessarrily. Client would just omit an unknown mapping type if it is 
not required or would just ignore whole operation if the unknown mapping is 
requred.
Quite a lot depends on how the IRI template is defined, but query string 
parameters can be exploded safely - it's up to the server in this matter.

>> We could also call it "simple hydra query syntax", describe it in the 
>> hydra spec and use a hydra URI for it, for that allows you to describe 
>> tpf in terms of hydra and not the other way around.
>That's what I'm after indeed.
Just wondering how complicated it might be.

>> The difference between hydra:filter and this suggestion is really only 
>> that urlSyntax allows to plug in external url syntaxes
> The ability to plug in is definitely a necessity; but this should only be 
> needed for complex cases IMHO.
I was thinking if we actually need "strongly" mapped mappings. Client could 
be sensitive to the mapped property itself. If it understands the IRI - take 
it, if not - leave it.

>> BTW odata and opensearch are not really a good fit for uritemplates. I 
>> like Tomasz's idea to have pluggable filtering mechanisms.
Actually OData is quite a good fit for IRI templates. I've just implemented 
this approach in my URSA - it's a simple query string property that can be 
fed with an extensive filtering expression.

>Pluggable is fine; but there should be sensible defaults out of the box.
Indeed we need to have in the spec what client MUST understand, but having 
filtering language in the spec is something a subject for discussion for me.

>> Can you line out a use case where the machine requires a detailed, case 
>> by case description of the query syntax with allowed comparison 
>> operators, allowed usage of AND and OR etc., where no human is involved?
>Yes: I envision a client that is able to query any API with a uniform query 
>language.
I'm just wondering on how the automated client would decide how and when to 
use AND/OR on it's own. Maybe by analyzing property's range and domain it 
could find i.e. that some values are disjoint classes, but still it's a long 
shot prune to errors.

Best

Karol

Received on Thursday, 18 February 2016 21:56:03 UTC