SODA Gripes (5) No single-value arguments for intervals

[Patrick Dowler]

I'm just working on the interval section of WD-DALI-1.1 and it isn't
clear if we came up with a consensus here. I have already enahnced it
to allow for integer and floating point intervals of the various
datatypes in VOTable. I see these options:

1. datatype="<numeric>" arraysize="2*" xtype="interval" : allows the
interval containing one value to be serialised as such, SIA-2.0 is
compatible

2. datatype="<numeric>" arraysize="2" xtype="interval" : allows the
interval containing one value but it has to be serialised as "<num>
<num>", SIA-2.0 spec is not compatible

2a. consider this detail in SIA-2.0 a mistake: modify the test and
examples as an erratum for SIA-2.0

2b. restrict SIA spec in next version: modify the text and examples in SIA-2.1

In either 2a or 2b, implementations could still accept single values
if they want to and the interpretation would be unsurprising so
SIA-2.0 services would not become invalid by doing so.

The problem is people implementing clients that rely on that SIA-2.0
behaviour. Are there any?

On 4 March 2016 at 02:46, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Hi James,
>
> On Thu, Mar 03, 2016 at 09:57:40PM +0000, James.Dempsey at csiro.au wrote:
>> I'm not sure if my post on this reached the list, but I still have
>> the concern that we should maintain consistency between the same
>> parameters for SIA2 and SODA where possible.
>
> I agree we should not have special rules in protocols, but in this
> case I'd say SIAv2 is the oddball, at least relative to current DALI
> drafts.
>
> I had mildly protested these single-value "intervals" (e.g., a
> mail to dal at ivoa.net from 28 Aug 2015 that interestingly didn't make
> it to the archives -- hm):
>
>   [...]
>
>   I'd finally like to register my reservations to the idea that single
>   values can be passed into double[2]/xtype=INTERVAL-typed parameters,
>   as we're again lying about types, which will fall on our feet[1]
>   while, as far as I can see, not adding any functionality. But that's
>   just for the record and *not* arguing against this going forward.
>
>   Let's tackle server-side processing ("Accessdata") now!
>
>   Cheers,
>
>           Markus
>
>   [1] I'd argue it already is on the way to hit a toe.  If I read
>
>     Find data that includes 21cm:
>
>     BAND=0.21
>
>     The scalar value 550, equivalent to [550,550]:
>
>     BAND=550
>
>   (p. 14), I get a little confused -- is BAND=0.21 equivalent to
>   [0.21, 0.21]?  And if it is, why isn't it stated there while it's
>   pointed out for BAND=550?  Fortunately, there's the next paragraph
>   properly explaining things, but that part then leaves one wondering
>   why one would not simply write 550 550 instead of 550 and save all
>   the extra words and code...
>
> I stand by that now (with the qualification that arraysize="2*" means
> we don't really lie about types, ok) and would propose to fix this in
> SIAPv2's next version and have consistency in that way.
>
> Cheers,
>
>         Markus



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada