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

[James.Dempsey at csiro.au]

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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160229/fdd5950a/attachment-0001.html>