<div dir="ltr"><div><div><div><div>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...<br><br><br></div>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.<br><br></div>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.<br><br></div>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.<br><br></div>Pat<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 February 2016 at 02:29, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DAL,<br>
<br>
I trust you've all been looking forward to it: here's the next<br>
installement in the series on SODA gripes (but this one is short and<br>
relatively straightforward).<br>
<br>
This is about the following regulation in the current Draft<br>
<br>
"If there is one single value the interval is assumed to be<br>
infinitely small (a scalar value)."<br>
<br>
(e.g., on BAND, but it seems to be intended as a general rule).<br>
Essentially, by this rule,<br>
<br>
BAND=550<br>
<br>
would be equivalent to<br>
<br>
BAND=550 550<br>
<br>
I propose to strike this rule.<br>
<br>
It does not add new capabilities but is a significant pain in<br>
implementation, since you'll somehow have to teach your VOTable<br>
tabledata parser to suddenly accept a single value into a 2-array<br>
(and really, what should it put into the second element of that<br>
2-array? NULL? Please not, remember there's integers, too).<br>
<br>
And even if single values weren't a big pain:<br>
<br>
$ python -c "import this" | grep preferably<br>
There should be one-- and preferably only one --obvious way to do it.<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
<br>
For bookkeeping, here's the current state of my series of gripes,<br>
unnumbered means "you can still look forward to it". The names in<br>
parenthesis in case of unresolved items are the persons that more or<br>
less promised to get back to these issues:<br>
<br>
(1) The big one (François)<br>
(2) No gratuitous xtypes (OK)<br>
(3) In-DAL SODA descriptor optional, introductory text (François)<br>
(4) Mandated multiplicities considered harmful (Pat)<br>
(5) No single-value arguments for intervals (everyone)<br>
() @value and @ref semantics documented for PARAMs<br>
() Spatial coverage discovery and the RA and DEC parameters<br>
() Pixel coutouts: PIXEL_n<br>
() Behaviour for no-ID queries? For queries with only ID?<br>
() POS doesn't have an xtype<br>
() Examples stuff: example example, and perhaps a dl-id term?<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>