Issue in SODA standard: BAND param max values

[Markus Demleitner]

Hi Alberto,

On Tue, Apr 07, 2020 at 12:00:56PM +0200, alberto micol wrote:
>     <VALUES>                                                           
>       <MIN value="3e-7"/>
>       <MAX value="8e-7"/>
> 
> The Issue
> 
> That is wrong, because the value attributes in the MIN and MAX
> elements are spelt as if the PARAM were of arraysize=“1”.

Well -- let's rather say it's a lacuna in the VOTable spec.

The fundamental problem is that you cannot order arrays (without
breaking arithmetic).  Hence, min and max don't have a "natural"
meaning with arrays, and the VOTable hasn't said what they should
mean instead.

Back when we discussed about POLYGON and the definition of limits, I
had hoped I could convince people that the only sensible semantics
would be that arrays are (at least at first) "homogeneous"
structures, which means that, in principle, min and max are the same
for all elements.  That would mean that MAX/@value would have to be
parsed as for FIELD/@datatype, ignoring FIELD/@arraysize.  That is
what the 1D SODA examples assumed.

As I said, VOTable doesn't say anything about that, and in the
POLYGON days Pat used that freedum to put a bounding box into
MAX/@value.  I was severely dismayed (see
http://mail.ivoa.net/pipermail/dal/2016-November/007633.html and
followups), but given there was no sane alternative option for
conveying the coverage, I eventually gave in.

Because of this usage (and, ok, also DALI xtype="circle"), I suppose
we can't put the IMHO desirable interpretation (MIN/@value ignores
arraysize) into the VOTable spec.

I believe essentially the only alterntive interpretation we can
prescribe without causing mayhem is min and max per element.

Which isn't this:

> The PARAM expresses an interval, and as such the only possible way to describe its limits is by stating:
>     <VALUES>                                                           
>       <MAX value=“3e-7 8e-7"/>
>     </VALUE>             
> similarly to what is already done for the CIRCLE and other non scalar params.

While it's somewhat in line with our POLYGON hack, would be really
undesirable, because essentially we'd be encoding a minimum in the
maximum element.  Also, we'd be blocking MIN and MAX for the
inhomogeneous arrays we now have committed to (see circles, where
arr[0] and arr[1] are coordinates and arr[2] is a radius), not to
mention arrays longer than 2 elements.

So, I believe given what we've done with POLYGON and given the path
we've entered with CIRCLE the only thing we can do is add in VOTable
something like

  For arrays, MIN/@value and MAX/@value, if given, must specify as
  many elements as defined by the parent's arraysize; if specified
  for a variable-length array, behaviour is undefined by VOTable
  [that's another lex POLYGON).  For each element of the array, the
  corresponding element in @value gives minimum and maximum for that
  particular element.[Footnote: this is for applications like DALI
  circles, where the various elements of an array have different
  roles].

Well, if we wanted we could say "give up to arraysize elements; when
fewer values are specified in MIN/MAX than are in the array, the last
value is repeated", which would fix the situation for homogeneous
(a.k.a. sane) arrays, and would let us allow MIN/MAX on
variable-length arrays.

This would then mean that the way this would need to look like is

   <VALUES>                                                           
      <MIN value=“3e-7 3e-7"/>
      <MAX value=“8e-7 8e-7"/>
   </VALUE>             

And yes, this still needs a fix in the SODA examples, which were
written before the POLYGON/MAX idea.  Sorry I've not caught it
earlier.

       -- Markus