New SIA v2 proposal

[François Bonnarel]

Hi all,
     With my "Dal char hat".

      What we have is not perfect but it's workable. SIAV2.0 is SIAV2.0 
, I mean "2.0", I mean ".0". There will be a ".1" and so on.
There is a lot to be discussed for a PQL: what is it for and what it 
should look like?
      There will be a session with an open discussion of this in Sydney 
(DAL future), I hope.
Cheers
François
Le 16/09/2015 09:09, Markus Demleitner a écrit :
> 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)