<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=&quot;2&quot; xtype=&quot;interval&quot; (both bounds required) and arraysize=&quot;2*&quot; xtype=&quot;interval&quot; (one or two values) which permits a scalar value...<br><br><br></div>In WD-DALI the section on intervals simply sys arraysize=&quot;2&quot; 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&#39;t see anything in DALI that prevents uxing xtype=&quot;interval&quot; with all numeric types (floating point and integer), so I will make that change in the next WD.<br><br></div>Personally, I&#39;m not too attached to the single number means scalar value... I agree it doesn&#39;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">&lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>&gt;</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&#39;ve all been looking forward to it: here&#39;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>
  &quot;If there is one single value the interval is assumed to be<br>
  infinitely small (a scalar value).&quot;<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&#39;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&#39;s integers, too).<br>
<br>
And even if single values weren&#39;t a big pain:<br>
<br>
$ python -c &quot;import this&quot; | 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&#39;s the current state of my series of gripes,<br>
unnumbered means &quot;you can still look forward to it&quot;.  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&#39;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>