New SIA v2 proposal

[Markus Demleitner]

Hi DAL,

Uh-hu, now *I* am getting unhappy...

On Tue, Sep 15, 2015 at 12:14:00PM -0700, Patrick Dowler wrote:
> On 14/09/15 11:20 PM, Walter Landry wrote:
> >I am not comfortable with this approach.  If you make people put
> >something in that slot that is not 'NULL', it does not feel like a
> >NULL.  VOTable defines +Inf and -Inf, and it would have the expected
> >effect.  Users do not understand NaN as well as infinity.

Well, users shouldn't even see that unless they're non-naive -- this
is a *protocol* that's implemented by libraries and clients, *not* a
user interface unless users are devious, in which case they can be
expected to study a spec.

> It is really unfortunate that someone who knew that +Inf and -Inf were
> supported (I didn't) wasn't there in Sesto. Still, as editor I should have
> looked more closely at the VOTable spec before writing those examples :-(
> 
> Anyway, the principle being (incompletely) adopted is that parameter values
> should be serialised the same way as VOTable arrays (of numbers in this
> case). The phrase "range values are encoded using the VOTable array
> serialisation" means that NaN, +Inf and -Inf are all allowed (we didn't
> explicitly say they are not), although we don't give any such examples
> except for unspecified bounds aka NaN.
> 
> ** So: Walter is completely right and the examples should be fixed to show
> use of +inf and -Inf. **
> 
> As for your specific comfort with NaN usage here, the real problem is that
> we were wanting to allow "unspecified bound" which turns out to be NaN. I
> agree it has some ugly all over it...  Allowing unspecified bounds (NaN)
> really adds no value at all at this point since you have to put something in
> the param value anyway; that could go.

Well, whatever we do, there should be one way to do things and one
way only.  If we say "open bound" is +/-Inf, then we should
explicitly say behaviour on NULL is undefined or preferably NULL should
raise an error.

I happen to believe going for Inf is not a good idea, as it won't
work for integers (where with NULL-is-open we at least can use
the nullvalue mechanism, bad as it is).  It's also less
straightforward, as you'll have to map an "empty" on some input
widget to +Inf or -Inf depending on whether it's a lower or upper
bound, whereas mapping "empty string" to NULL and then serialize that
into whatever NULL representation you happen in an output format is
very natural.

It's not a huge deal, but accumulating lots of such small annoyances
it what makes protocols a pain to implement.

So -2 from me on +/-Inf, but I won't try to veto it.

Cheers,

          Markus

(who still wishes he could have convinced you that atomic parameters
are the way to go, as that entire discussion wouldn't have happened
with them)