SODA, section 4.3

[Markus Demleitner]

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.

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.

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.  

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