Issue in SODA standard: BAND param max values

[alberto micol]

Thanks Markus,

Allow me to correct one thing in your message, hoping that this helps clarifying the matter…
You said:

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

but, no, we would not be encoding a minimum in the maximum element,
simply because the “minimum” in your sentence refers to a different concept
and not to the datatype of the element at hand, which is an “interval”!

Given that the element is “interval”, its MAX must represent the maximum extent of the interval.
And this is exactly what astropy/pyvo checks for and complains about.

In the above sense, MAX="3e-7 8e-7” is not conveying any “minimum” value, as you call it,
and hence there is no confusion possible.

Important to note: one can define a single MAX value for an interval type, 
while instead in general there are infinite MIN possible intervals contained in the max interval,
which shows that MIN loses meaning and should not be used for intervals.

Same for the circle: MAX=“ra dec radius” represents the maximum circle where valid data can be found.
And same for polygon too.

Alberto

> On 7. Apr 2020, at 14:00, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> 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