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

[Patrick Dowler]

The way DALI is written now (maybe not 100% clear) the serialisation of
intervals is in terms of VOTable table data serialisation. So, if we allow
integer and long intervals then any valid integer or long value can be
used; since they don't have values for infinity, open-ended intervals
cannot be expressed. The examples have to be clear but DALI would not
introduce any new special values. (I'm currently using the parse/format
classes from my votable reader/writer to parse parameters in services and
being able to do that is really nice.)

We first needed interval for energy bounds and time bounds (MJD numbers) so
that's why we started with floating point values: smaller scope.

I think we could allow the scalar value interval with one number so that
SIA-2.0 is "DALI-compliant"; it means saying that is arraysize="2*"
(instead of 2). I only have to support that in one piece of code to make it
consistent across all our votable and DALI-parameter services so I don't
see that kind of special case being problematic. In general DALI (as a
"common patterns" interface) sometimes sets patterns and sometimes extracts
and sanctions patterns (it was initially written by extracting current
practice and lopping off the inconsistencies).

Pat

On 29 February 2016 at 12:23, <James.Dempsey at csiro.au> wrote:

> Hi Markus and Pat,
>
>
>
> The same syntax of BAND=550 is present already in the SIAP v2
> recommendation (section 2.1.2). As we are already committed to it in SIAP I
> think it is better to try for consistency between the two and thus retain
> the single value arguments in SODA. That way parameter parsing and
> client code can be shared between SIAP and SODA.
>
>
>
> After looking again at SODA section 3.2.2, I think it would be useful to
> have examples which make it clear that the values are wavelengths in metres
> though, e.g. BAND=0.21 and BAND=5.00E-7 5.5E-7
>
>
>
> Cheers,
>
> James Dempsey
>
> CSIRO Australia
>
>
>
> ------------------------------
> *From:* dal-bounces at ivoa.net <dal-bounces at ivoa.net> on behalf of Patrick
> Dowler <pdowler.cadc at gmail.com>
> *Sent:* Tuesday, 1 March 2016 4:22 AM
> *To:* <dal at ivoa.net>
> *Subject:* Re: SODA Gripes (5) No single-value arguments for intervals
>
> That was an idea to make simple things simple to do. In parameter
> descriptor terms it seems to be the difference between arraysize="2"
> xtype="interval" (both bounds required) and arraysize="2*" xtype="interval"
> (one or two values) which permits a scalar value...
>
>
> In WD-DALI the section on intervals simply sys arraysize="2" and has no
> text or examples with scalar values. It is my intention to find a
> definitions (for all the xtypes defined in DALI) that can be used in SODA
> and TAP.
>
> Aside: I don't see anything in DALI that prevents uxing xtype="interval"
> with all numeric types (floating point and integer), so I will make that
> change in the next WD.
>
> Personally, I'm not too attached to the single number means scalar
> value... I agree it doesn't add any capability, but it might make a common
> mistake do what was probably intended.
>
> Pat
>
>
> On 29 February 2016 at 02:29, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
>
>> Dear DAL,
>>
>> I trust you've all been looking forward to it: here's the next
>> installement in the series on SODA gripes (but this one is short and
>> relatively straightforward).
>>
>> This is about the following regulation in the current Draft
>>
>>   "If there is one single value the interval is assumed to be
>>   infinitely small (a scalar value)."
>>
>> (e.g., on BAND, but it seems to be intended as a general rule).
>> Essentially, by this rule,
>>
>> BAND=550
>>
>> would be equivalent to
>>
>> BAND=550 550
>>
>> I propose to strike this rule.
>>
>> It does not add new capabilities but is a significant pain in
>> implementation, since you'll somehow have to teach your VOTable
>> tabledata parser to suddenly accept a single value into a 2-array
>> (and really, what should it put into the second element of that
>> 2-array? NULL?  Please not, remember there's integers, too).
>>
>> And even if single values weren't a big pain:
>>
>> $ python -c "import this" | grep preferably
>> There should be one-- and preferably only one --obvious way to do it.
>>
>> Cheers,
>>
>>            Markus
>>
>>
>> For bookkeeping, here's the current state of my series of gripes,
>> unnumbered means "you can still look forward to it".  The names in
>> parenthesis in case of unresolved items are the persons that more or
>> less promised to get back to these issues:
>>
>> (1) The big one (François)
>> (2) No gratuitous xtypes (OK)
>> (3) In-DAL SODA descriptor optional, introductory text (François)
>> (4) Mandated multiplicities considered harmful (Pat)
>> (5) No single-value arguments for intervals (everyone)
>> () @value and @ref semantics documented for PARAMs
>> () Spatial coverage discovery and the RA and DEC parameters
>> () Pixel coutouts: PIXEL_n
>> () Behaviour for no-ID queries?  For queries with only ID?
>> () POS doesn't have an xtype
>> () Examples stuff: example example, and perhaps a dl-id term?
>>
>>
>
>
> --
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
>



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160229/20d5e8ca/attachment.html>