<div dir="ltr"><div><div>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&#39;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&#39;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.)<br><br></div><div>We first needed interval for energy bounds and time bounds (MJD numbers) so that&#39;s why we started with floating point values: smaller scope.<br><br></div>I think we could allow the scalar value interval with one number so that SIA-2.0 is &quot;DALI-compliant&quot;; it means saying that is arraysize=&quot;2*&quot; (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&#39;t see that kind of special case being problematic. In general DALI (as a &quot;common patterns&quot; interface) sometimes sets patterns and sometimes extracts and sanctions patterns (it was initially written by extracting current practice and lopping off the inconsistencies). <br><br></div>Pat<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 February 2016 at 12:23,  <span dir="ltr">&lt;<a href="mailto:James.Dempsey@csiro.au" target="_blank">James.Dempsey@csiro.au</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Markus and Pat,</p>
<p> </p>
<p>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.</p>
<p> </p>
<p>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</p>
<p> </p>
<p>Cheers,</p>
<p>James Dempsey</p>
<p>CSIRO Australia<br>
</p>
<p><br>
</p>
<div>
<div><font size="2">
<div><br>
</div>
</font></div>
</div>
<div style="color:rgb(33,33,33)">
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> <a href="mailto:dal-bounces@ivoa.net" target="_blank">dal-bounces@ivoa.net</a> &lt;<a href="mailto:dal-bounces@ivoa.net" target="_blank">dal-bounces@ivoa.net</a>&gt; on behalf of Patrick Dowler &lt;<a href="mailto:pdowler.cadc@gmail.com" target="_blank">pdowler.cadc@gmail.com</a>&gt;<br>
<b>Sent:</b> Tuesday, 1 March 2016 4:22 AM<br>
<b>To:</b> &lt;<a href="mailto:dal@ivoa.net" target="_blank">dal@ivoa.net</a>&gt;<br>
<b>Subject:</b> Re: SODA Gripes (5) No single-value arguments for intervals</font>
<div> </div>
</div>
<div>
<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><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888">
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div>Patrick Dowler<br>
</div>
Canadian Astronomy Data Centre<br>
</div>
Victoria, BC, Canada<br>
</div>
</div>
</font></span></div>
</div>
</div>
</div>

</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>