SIA-2.0: query params for string values

[Marco Molinaro]

Hi all,
really in short (my opinion): equals + case-sensitive.

In some more detail.

2014-06-26 9:25 GMT+02:00 Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
:

>
> On Wed, Jun 25, 2014 at 09:53:34AM -0700, Patrick Dowler wrote:
> > Now, we have a proposal to define string-value comparisons such that:
> >
> > FOO=abc
> >
> > is satisfied if "abc" matches a substring of the stored value (foo
> > contains "abc"). I haven't really thought this through, but there are
> > cases where exact match is the  better behaviour (e.g.
> > ID=<obs_publisher_did>) and others where substring matching is
> > arguably better... but I'm not convinced and I'm not crazy about
> > different params behaving differently depending on one sentence in
> > the spec.
>
> Nah, special rules by parameter are terrible, in particular because
> people will use custom parameters and everyone will be confused as to
> what semantics these have then, and again it's going to be hard to
> make such things discoverable.
>

I agree adding special cases to the par=val query system is confusing.
Even separating classes of parameters into: equal-izers and contain-ers
(that sounds quite simple, even using the hungarian notation Markus
referred to, e.g. one can think of eqFOO=bar and conFOO=baz) has the
drawback of adding maintenance work on the specification of the interface
and potentially leading to a set of protocols all having simple but totally
dis-homogeneous parametric interfaces. Not to speak about the precedent
that creates so one can think of adding up classes of parameters more than
those two (startsWith, fullRegex, ....).


>
> For reasons of consistency (also with the outside world) "normal"
> parameter behaviour should be comparison for equality.  For special
> effects, I think we should point to ADQL.  If we insist we want
> special effects on our S-protocols, I'm again proposing extra
> parameters (may I throw in "Hungarian Notation" to give this a bit of
> academic credibility?) -- a service that actually supports partial
> matches would just declare support for a parameter
>
> FOO_PARTICLE
>
> and any value(s) given would allow partial matches; whoever adds
> parameters that do partial matching would use the _PARTICLE suffix,
> too.
>
>
But I don't like this too either, it sounds like a camouflaged parameter
query language, which, if it is needed to start homogenizing the way simple
protocols reacts to requests, I'd definitely prefer (and having time,
collaborate in).


> [either that or someone sits down and actually writes a full-blown
> query language -- VizieR's would be a good starting point with
> relatively few wrinkles to iron out; for strings, that might actually
> work out much better than it would for numbers as we wouldn't have to
> lie that blantantly about types here.]
>
>
> > A second complete orthogonal issue that has come up before is case
> > sensitivity. Should we define these comparisons to always be
> > non-case-sensitive? There is the fact that ObsCore dataproduct_type
> > has fixed lowercase values defined, so this doesn't make sense there,
> > but we can word carefully for such "enumerated" values to not open it
> > up to mixed or upper case there.
>
> Case-insensitivity is a bane for more reasons than I care to
> enumerate here.  After having written RegTAP, I start groping for my
> stress therapist's phone number as soon as I type the second
> "n" in the c-i word.
>
> I'd be fine with declaring _PARTICLE parameters as "ignoring case in
> some operator-defined sense"[1], as these need a lot of massaging, and
> aren't useful for "exact" matches anyway , but normal parameter
> matching should be case-sensitive ("compare for equality").
>
> 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?

Cheers,
     Marco

Off-topic

>
> [1] Note that case folding outside of plain ASCII is tricky business,
> including interesting locale dependencies (lower('I'), for instance,
> is different in Turkish from lower('I') everywhere else, and
> upper('ß') has caused snappy press reports over here.
>

I thought "sharfes s" had been removed from written German (wikipedia
disagrees with me however), has it only become optional?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140626/c1beb309/attachment-0001.html>