Clarification on DataLink service descriptor input parameters

[Patrick Dowler]

I think with the addition of xtype here this isn't just a plain old array.
With circle and polygon params we give just a MAX (minimum spanning circle
and polygon boundary respectively), so when collapsing this to 1-d I agree
that it probably should have been a MAX interval (bounds, just like
polygon).

So, in my view the example (and my datalink service that generates these)
is wrong; a human can grok the meaning but it's inconsistent with other
datalink examples/output.

If we can reach an agreement, I am willing to write an errata for the
example,  fix/clarify this in WD-DataLink-1.1, and fix my buggy service :-)

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Tue, 4 Oct 2022 at 03:56, Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> Hi Adrian,
>
> On Mon, Sep 26, 2022 at 07:53:14PM +0000, Damian, Adrian wrote:
> > <PARAM arraysize="2" datatype="double" name="BAND"
> >            ucd="em.wl" unit="m" value=""
> >            xtype="interval">
> >       <DESCRIPTION>Spectral cutout interval</DESCRIPTION>
> >       <VALUES>
> >         <MIN value="3.52631986e-07"/>
> >         <MAX value="9.21500998e-07"/>
> >       </VALUES>
> >  </PARAM>
> >
> > The VOTable parser in astropy does not like the syntax - it
> > expects, and I would say logically so, that MIN and MAX have the
> > type of the BAND param, i.e. an interval. Is there a reason not to
> > have the above MIN and MAX expressed as the maximum interval, i.e.
> > <MAX value="3.52631986e-07 9.21500998e-07”/>?
>
> Well, this has always been a very sore spot (previously:
> http://mail.ivoa.net/pipermail/dal/2020-April/008330.html) -- and I
> think it needs to be discussed over on Apps, as it is really a
> VOTable problem.
>
> The meaning of MIN and MAX with arrays has never been properly
> defined.  Now, given that arrays are supposed to be "homogeneous"
> data structures -- all members "mean" about the same thing --, one
> can argue that arraysize should be ignored for MIN and MAX, i.e.,
> that they are always scalar.  I think that would certainly be the
> intent for OPTIONS and for VALUES/null (the latter of which is
> admittedly deprecated).
>
> Also, one cannot order vectors (respecting arithmetic); hence, a
> really well-defined MIN and MAX for arrays is not possible anyway.
>
> On the other hand, having component-wise MIN and MAX is of course
> possible (although that would have about as silly consequences of
> char arrays as the "ignore arraysize" convention).  But even then one
> would have to ask what such a multi-component MIN/MAX would mean with
> arraysize="*".
>
> This latter interpretation is what we introduced in soda (against my
> mild resistence, if I may say so,
> http://mail.ivoa.net/pipermail/dal/2016-November/007633.html).
>
> Well -- I'd say it's time to clarify this whole thing in VOTable.
> I'd kind of like the "give up to arraysize elements; when fewer
> values are specified in MIN/MAX than are in the array, the last value
> is repeated" I had proposed in April 2020, I must say on re-reading
> it.  This would help with the variable-length arrays and would indeed
> redeem the datalink example above.  Of course, it's a bit painful in
> implementation, but perhaps not overly so.
>
> Whatever we go for: someone would have to put it (and something on
> OPTIONS and VALUES/@null) into the VOTable spec.  I'd help out with
> it, but I don't want to push it along...
>
>            -- Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20221004/9f18f068/attachment.htm>