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

[François Bonnarel]

Hi all
On 29/02/2016 21: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.
>
Yes, this is a very good example which shows that it's interesting to 
consider SIAV2, and SODA protocols as brother protocols. We actually 
changed SIAV2 syntax before recommendation, in order to be consistent 
with what was proposed in the mean time for AccessData/SODA (discussion 
in Sexto). It would be a pity to destroy this consistency now.
  One strong reason to do that is that  very important use case is when 
the nD-ROI used in SIAV2 query becomes the nD-limits of the cutouts with 
SODA
Same syntax different outputs of course.
The idea for admitting both a single value and an array of two values is 
that TIME and BAND parameters are intended to manage all kind of 
structures related with the parameter. It is a little structure 
actually. And Pat gave a good reason to keep that.

If we want to change that in SODA  we have to make an erratum to SIAV2, 
that for sure is important.
Cheers
François
>
> 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/20160301/51ba92bb/attachment-0001.html>