SIA-2.0: query params for string values

[Jose Enrique Ruiz]

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




2014-06-30 15:57 GMT+02:00 Marco Molinaro <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>:
>
> 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>
>> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140630/66cc9cca/attachment-0001.html>