Caveat !!! Re: Special attention To Alberto Re: SODA erratum 3 proposal

[BONNAREL FRANCOIS]

Dear all,
I don't see any more discussion on this ion the last two monthes
After related discssions on the VOTable github repository : issue 
https://github.com/ivoa-std/VOTable/issues/32
and PR : https://github.com/ivoa-std/VOTable/pull/38
I completely rephrased the SODA erratum 3 
https://wiki.ivoa.net/twiki/bin/view/IVOA/SODA10Err3

So if nobody is complaining about getting rid of  2D array MIN/MAX for 
intervals maybe we could adopt it at next TCG meeting on sunday ?
Cheers
François

Le 16/02/2023 à 00:11, BONNAREL FRANCOIS a écrit :
>  A sentence had been suppressed in my previous email. Sorry about this !
> Le 15/02/2023 à 18:30, BONNAREL FRANCOIS a écrit :
>> Le 14/02/2023 à 18:48, Mark Taylor a écrit :
>>> Alberto,
>>>
>>> On Tue, 14 Feb 2023, alberto micol wrote:
>>>
>>>> Before answering Francois’ request for my comments,
>>>> I need to ask a question to Mark.
>>> I'm assuming you're asking me with my taplint/votlint hat on.
>>>   
>>>> I do agree with you, Mark, that using scalar MIN and MAX values
>>>> for a xtype=“interval" element is the least surprising semantics,
>>>> but...
>>>>
>>>> Votable 1.4 seems to require that the MIN and MAX <VALUES> must be of the same arraysize as the parent parameter.
>>> Is that true?  I may be missing it but I don't see text in VOTable 1.4
>>> that says that.  I don't see anything much in the text that mandates
>>> what has to go into the MIN/MAX value attribute, beyond a couple of
>>> examples.  It's sort of obvious for scalar numeric fields,
>>> but far from obvious for array values.  For that reason
>>> (as far as I can remember) votlint/taplint does not attempt to
>>> validate the MIN/MAX values - currently, you can write anything
>>> in there and votlint/taplint will not tell you off.
>>>
>>> If future versions of the VOTable standard are clearer about what
>>> can go into MIN and MAX, I expect I will update the validator logic
>>> to report non-compliance.
>>>
>>>> Indeed ASTROPY complains if the arraysizes of the VALUES MIN and MAX are not the same as for the PARAM:
>>>> WARNING: E02: ?:?:?: E02: Incorrect number of elements in array. Expected multiple of 2, got 1 [astropy.io.votable.converters]
>>> So it looks like the astropy validator made a different decision about
>>> how to validate those elements than I did.
>>>
>>>> I understand VOTable 1.5 is supposed to change this; the new text reads:
>>>>> When the parent of a VALUES element does have an xtype, special rules apply;
>>>>> clients should only try to parse limits of xtyped fields when they know the xtype.
>>>> The text “when they know the xtype” confuses me quite a bit. What does that mean in practice? For example:
>>>> How will a validator understand how to validate a votable with MIN/MAX VALUES expressed with arraysizes different than its parent element,
>>>> as suggested for the MIN MAX of an interval ?
>>> I think the idea is that where a known xtype is present, parsers
>>> (and validators) should interpret the MIN/MAX in accordance with
>>> special rules about MIN/MAX that are provided along with the
>>> xtype definition (most likely in DALI); those rules will explain
>>> what the constraints are for that xtype.  If an unrecognised xtype
>>> is present, parsers can't make sense of MIN/MAX and shouldn't try.
>>> In absence of xtype, MIN/MAX has to be a scalar with "obvious"
>>> semantics.
>>
>> If we choose the scalar generic solution then the following text in 4.2
>>
>> "For float-valued intervals (e.g., the standard BAND and TIME 
>> parameters),VALUES/MINandVALUES/MAXshould be used to communicate the 
>> range of values for which clients can expect to receive data"
>>
>> should become
>>
>> For float-valued intervals (e.g., the standard BAND and TIME 
>> parameters),VALUES/MINandVALUES/MAXshould be used to communicate the 
>> range of values for which clients can expect to receive data as 
>> stated for MIN/MAX values in the generic case starting from VOTable 1.5"
>>
>>
>> But in the same 4.2 subsection we give examples for CIRCLE and 
>> POLYGON parameters and say
>>
>> 1 ) "For CIRCLE, only a MAX is given. It contains three floating 
>> point values, separated by whitespace. These correspond to the RA and 
>> Dec of the center of a spherical circle covering the dataset, and a 
>> radius of such a covering circle. "
>>
>> Which look like a definition of how we could  interpret MIN/MAX in 
>> the case of xtype="circle" in DALI-next
>>
>>  2 ) "For POLYGON, again only aMAXis given. It consists of a sequence 
>> of floating-point values, again separated by blanks, describing RA 
>> and Dec of the vertices of a spherical polygon covering the dataset. 
>> Data providers are encouraged to choose a minimal polygon. Example:"
>>
>> Which look like a definition of how we could  interpret MIN/MAX in 
>> the case of xtype="polygon" in DALI-next
>>
>> So for consistency in this subsection we could also write
>>
> "For float-valued intervals (e.g., the standard BAND and TIME 
> parameters), only aMAXis given. It contains two floating-point 
> values,  separated by a blank. These correspond to the bounds of the 
> daraset on the corresponding axis. Example"
>>
>> We could also add in parenthesis (xtype="interval, xtype="circle", 
>> xtype="polygon") at the right place in the text
>>
>> Thoughts ?
>>
>> Cheers
>>
>> François
>>
>>>> One could even write:
>>>> <PARAM arraysize=“2” xtype=“interval” name=“BAND”…>
>>>> <VALUES>
>>>>   <MIN arraysize=“” …>
>>>>   <MAX arraysize=“55” …>
>>>> </VALUES>
>>>> </PARAM>
>>>> Votable 1.5 seems to allow such possibility !
>>> No, since (a) where the interval xtype is defined there should be
>>> rules about how to use MIN/MAX and (b) there is no arraysize
>>> attribute defined on the MIN/MAX elements.
>>>
>>>> In which case the validator will need to simply omit any check on those MIN MAX values, right?
>>>> That does not seem particularly healthy.
>>> About what one can not speak, one must remain silent.
>>>
>>> Mark
>>>
>>> --
>>> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
>>> m.b.taylor at bristol.ac.uk           http://www.star.bristol.ac.uk/~mbt/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20230505/4818ad32/attachment-0001.htm>