SIA-2.0: query params for string values

[Marco Molinaro]

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/491b2a1c/attachment.html>