SODA, section 4.3

[Patrick Dowler]

Comments inline...

On 10 November 2016 at 01:56, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Hi Pat,
>
> On Wed, Nov 09, 2016 at 12:17:18PM -0800, Patrick Dowler wrote:
>> The reason intervals are treated that way is consistency.  My reading
>
> Well, we're going to be inconsistent anyway -- there's no way to
> reconcile our ugly hacks on CIRCLE and POLYGON with the semantics
> intended by VOTable in (not only, I claim) my reading.

Well, the VOTable xsd says that value in MIN/MAX is any string, so
interpretation
is completely up to the parser or application. I don't see any reason that  any
of the attributes of the enclosing PARAM should be ignored when interpreting it.
I think it is clear they are intended to be used, and not just
datatype. We are just
taking this to the logical conclusion when  an xtype is specified.

I would not do this for an xtype where MAX had no possible meaning, but for any
datatype+xtype that defines a set of values (interval, circle, polygon
define sets of
values) this is just the maximum extent that includes all those values.

> Now, we don't need these hacks when the arrays we're talking about
> actually *are* arrays (i.e., homogeneous sequences).  So, the
> question in my view is: do we want to be consistent with the hacks or
> do we want to be consistent with "mainstream" use?  [and, I might
> add, also perhaps reduce the reservations uttered by the VOTable
> stewards in http://wiki.ivoa.net/twiki/bin/view/IVOA/SODARFC, point 7
> in Pierre's comments]
>
>> of the VOTable spec is that the value of the MIN and MAX  should be
>> interpreted using the datatype, arraysize, units, and xtype of the
>> parent param and since the param in arraysize="2" xtype="interval" the
>> value of the MAX has to be of that form. That is the only thing a sane
>> client can try to do [implemented: works].
>
> Hm... no.  Admittedly, VOTable is a bit hazy here, which is why we
> *might* just get away with what we do to VALUES for CIRCLE and
> POLYGON. But even talking about minimum and maximum really precludes
> using array literals (as they are not orderable preserving
> arithmetic).  Language like "The domain may therefore be defined as a
> single interval" (VOTable 1.3, p. 16) reinforces this notion.

That was undoubtedly written before xtype was introduced in VOTable-1.2
so I'd suggest that the full implications of xtype were not apparent.
Still, if we
do this with circle and polygon then we can do it with interval and I that means
xtype usage dictates interpreting values in MAX. VOTable-2.0?

> Even more importantly (and in case people want to propose
> component-wise comparsion), I'm convinced all VOTable libraries that
> care to do anything about it at all will interpret VALUES/@null in a
> way that the content is not a representation of a full array
> representing NULL but of a value of datatype (ignoring arraysize)
> intended to represent NULL.
>
> So: I'd argue there's little room for interpretation: VALUES uses
> to @datatype alone, @arraysize, @xtype (or @unit, @ucd, or whatever)
> cannot and do not apply.
>
>> I will admit to consistently abusing the meaning of MAX; in all cases
>> it means something like "this is the maximum extent that is useful"
>> and it has that same meaning for all these xtypes. It just looks
>> simpler with interval to separate the bounds into MIN and MAX, but it
>> makes parsing the values worse, not better. Yeah, it looks funny if
>
> ...except if you're using a standard VOTable parser, which will most
> certainly try to convert MIN/@value and MAX/@value to what datatype
> says, and for a good reason.

If they ignore other attributes that describe the type, the are wrong. I'm
sure no one ignores unit...

> Saying "but we've defined xtype" isn't a valid excuse either.  What
> xtype should enable is that clients or libararies "in the know" can
> apply extra smarts, while generic code will still "do the right
> thing" when serialising and deserialising VOTables.  If we require
> support for an xtype to allow safe parsing of MIN and MAX, that plan
> becomes rather hollow.
>
> It's bad enough that we break things with CIRCLE and POLYGON, and I
> have hopes we might be able to fix them later, when STC 2.0, VO-DML,
> and its VOTable serialisation get off the ground.  But let's
> not go on stomping on VOTable (and plain math that says you can't
> order arrays), in particular not when there's no dire need to do so
> and standard use will just do fine.
>
>
> Also: Any comments on the general sanitation of sect. 4.3 (where I
> propose to define a bit more formally what the intention is and in
> return drop material repeated from Datalink)?  Can we agree on that
> and just drop the text independent of interval metadata forms in?
>
>         -- Markus



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