SIA-2.0: query params for string values

[Patrick Dowler]

What Ger proposes is more complicated than it looks because we only have 
a parameter name and value. The = we have is the one in the normal http 
parameter syntax and I am convinced that the normal behaviour of FOO=bar 
should be strict equality. We don't really have operators in any sense 
that can be extended (with more operators).

In any case, if you did have operators, you would also need a mechanism 
so you could use those character(s) literally; that was always the death 
of the wildcard discussions we had around target names... and for pretty 
good reason as it gets messy fast.

Pat

On 11/07/14 10:30 AM, François Bonnarel wrote:
> Hi all,
>      I just reviewed what we have currently in the PR for the
> string-valued parameters. ID requires case insentive equality, the
> others should admit with various interests strict equality or
> case-insentive equality or inclusion.
>      In these conditions I think Ger proposal is reasonable. = will mean
> strict equality, and we could use ~= for IVORNS. < will be interesting
> for Instruments and facilities.
> Regards
> François
> Le 01/07/2014 08:29, Ger van Diepen a écrit :
>>
>> I'm not that familiar with the DAL specifications, but I assume an
>> operator like = or < has to be supplied. Why not also support operator
>> ~= meaning about equal. It can be used for floating point values (e.g.
>> relatively to 1e-5), but also for this string case (substring,
>> case-insensitive).
>>
>> It is used in TaQL.
>>
>>
>> Ger
>>
>> >>> Jose Enrique Ruiz <jer at iaa.es> 6/30/2014 6:36 PM >>>
>>
>> Hi DAL
>>
>>
>> for the params: collection, facility_name, instrument_name and
>> target_name,I would just provide the vision of a potential DAL-user.
>> This is that in the case I didn't know the *exact values* of these
>> textual fields (they are not physical numeric values, but curation
>> metadata and I guess not so easy to infer out of the blue) or several
>> archives provide slightly different values for these fields, the ideal
>> response would be provide products satisfying "substring match" and
>> "non-case sensitivity", as it is the case for registry queries by
>> keyword in i.e. Topcat.
>>
>>
>> This does not mean that I'm voting for substring match and
>> non-case-sensitive, maybe all this may be solved client side, I am
>> just saying that for a DAL-user the perception of these params may be
>> not so different from those used when performing a query in the
>> registry by keywords. I think a TAP-user may have a different
>> perception, more oriented towards "equals match" and
>> "case-sensitivity", and if this discussion remained only in the scope
>> of ObsCore/TAP use cases I will strongly support equals and non-case
>> sensitive.
>>
>>
>> FWIW, DALI clearly states in 3.1.1 "Parameter values are case
>> sensitive unless a concrete DAL service specification explicitly
>> states that the values of a specific parameter are to be treated as
>> case-insensitive", though I do not see anything related to
>> equals/contains issues (we are very used to queries with numeric
>> values :), maybe we could find some light from Registry-queries use
>> cases. As I see it, in the ideal world all these params would be
>> issued from central resolution services (similar to resolution of
>> target names, filter names, etc.) integrated both in the client side
>> as well as in the server side (the curator mapping these values to
>> unique keys provided by these services..)
>>
>>
>> Hope it helps..
>>
>>
>>
>> Cheers
>>
>>
>> ---
>>
>> Jose Enrique Ruiz
>> Instituto Astrofisica Andalucía - CSIC
>> Glorieta de la Astronomía s/n
>> 18009 Granada, Spain
>> Tel: +34 958 230 618 <tel:%2B34%20958%20230%20618>
>>
>>
>>
>>
>>
>> 2014-06-30 15:57 GMT+02:00 Marco Molinaro <molinaro at oats.inaf.it
>> <mailto:molinaro at oats.inaf.it>>:
>>
>>     Hi Markus,
>>
>>     hi DAL-ers,
>>
>>
>>     2014-06-30 10:18 GMT+02:00 Markus Demleitner
>>     <msdemlei at ari.uni-heidelberg.de
>>     <mailto:msdemlei at ari.uni-heidelberg.de>>:
>>
>>
>>         Dear DAL,
>>
>>
>>         On Thu, Jun 26, 2014 at 09:12:33PM +0200, Marco Molinaro wrote:
>>         > 2014-06-26 9:25 GMT+02:00 Markus Demleitner
>>         <msdemlei at ari.uni-heidelberg.de
>>         <mailto:msdemlei at ari.uni-heidelberg.de>>
>>
>>         > > More precisely, I believe we shouldn't say anything about case
>>         > > folding in the protocol. That's because unfortunately,
>>         we're already
>>         > > knee-deep in case-insensitivity hell: IVORNs were defined
>>         as being
>>         > > c-i (which of course leads to no end of interoperability
>>         woes because
>>         > > few services actually treat them accordingly). So, if
>>         there were a
>>         > > PUBDID parameter (which could be useful in certain datalink
>>         > > scenarios), backend matching would have to be case
>>         insensitive. But
>>         > > that's a (regrettable) property of IVORNs, not the protocol.
>>         > >
>>         >
>>         > Here I thing I'm missing one point (or more, don't know):
>>         what means we
>>         > shouldn't say anything about case sensitivity? To me this
>>         reads like using
>>         > case sensitive values, otherwise both client and server will
>>         never know how
>>         > to robustly submit or respond to a request.
>>         > Delete the "I think" here above: What am I missing?
>>
>>         What I'm saying is: the protocol should say (if anything):
>>         "Parameters are compared for equality".
>>
>>         The trouble hidden in there is that we've already shot
>>         ourselves in
>>         the foot by defining equality for some relevant types in, as
>>         far as I
>>         am concerned, unexpected ways. IVORNs, for instance, are
>>         case-insensitive, so when you compare them for equality, you
>>         need to
>>         do some case-folding, whether you're talking SIAv2 or OAI-PMH:
>>         It's a
>>         property of the type, not of the protocol.
>>
>>
>>     Ok, so equality and case-sensitivity are bound together but IVORNS
>>     (e.g.) are a special case that complicate the interface behavior.
>>
>>     Can we start thinking of using [case-sensitive] request parameters
>>     that are compared for equality and explicitly state which are the
>>     already existing special cases where this fails to be exactly true?
>>
>>     If I remember correctly RegTAP already says something similar due
>>     to identifiers and other stuff.
>>
>>     I know that it'll complicate recommendation editing and curation
>>     but, once all protocols have interfaces that work on the same
>>     guidelines it'll be maybe easier to revert the "case-insensitivity
>>     hell" without clashing on existing implementations.
>>
>>     I don't know if this proposal can make sense.
>>
>>
>>     BTW, we hadn't too many contributions to this SIA-2.0 string
>>     valued query params discussion.
>>
>>
>>     Marco
>>
>>
>

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)