SODA gripes (2): Gratuitous xtypes

[Mark Taylor]

Hi Markus and DAL.

On Wed, 20 Jan 2016, Markus Demleitner wrote:

> In order to get on with my list of gripes, here's my second one.  In
> two sentences:
> 
> SODA should not define any xtypes.  That's DALI turf.
> 
> The concrete consequence: All specifications of xtypes except the
> interval should go from SODA standard parameters.

I am somewhat in agreement, but I wouldn't go quite as far as Markus.

> The reason simply is: They serve no purpose.  In the case of POS, not
> only do they serve no purpose, they're actually damaging.
> 
> Here's the background on xtypes: xtype is a VOTable attribute to
> FIELDs and PARAMs introduced in (I think) 1.2 because there was
> resistance to extending the VOTable type system to some types that
> were found desirable when delivering database tables, in particular
> timestamps and geometry values.
> 
> Retrospectively, I think it was a mistake to do this, because in the
> end, it just confuses VOTable's type system, and VOTable
> implementations will have to do something with all the types we're
> defining anyway or we have a major interoperability problem on our
> hands.  It'd have been much better to be honest about the feature
> creep and extend the type system in VOTable itself.

I disagree with this.  The point about having xtypes hanging off
an existing datatype is exactly that VOTable implementations
do *not* have to do something xtype-specific with them.
Consider a value described thus:

   <PARAM datatype="char" arraysize="19" xtype="iso8601"
          value="2016-01-20T10:08:25">

A general-purpose VOTable processing library or application
can perfectly well present the values to downstream software or
to the user as a string.  Time-aware software meanwhile can work
out how to convert it to an MJD or whatever.  Software that sees
an xtype it doesn't recognise can and should just ignore it,
and treat the data just as it would if it had no xtype
(though propagate the xtype value downstream where appropriate).
It's somewhat like a UCD or Utype in this respect, but it's
orthogonal to that, because it's to do with how to map
VOTable-friendly primitive datatypes to some other value domain,
rather than being concerned with semantics as such.  Doing it
like this protects us from having to constantly update the
VOTable standard, and hence general-purpose VOTable processing
software, every time we think of a new value domain that we
need to transport.  FITS has managed for however many decades
it is without having to update its type system, and the VOTable
type system is based on that (I consider this last point a
good argument, but if you're a FITS-hater, kindly pretend
I didn't say it).

> While that ship has sailed, it's important to limit the damage: let's
> at least be very cautious when introducing new xtypes lest we make
> VOTable unimplementable.  There should be exactly one place in which
> xtypes are defined.  It seems that one place is DALI.

I think that using DALI as the standard place to look for well-known
xtypes is an excellent idea, and I look forward to seeing the
relevant draft.  However, I don't agree on an embargo on non-DALI
xtype definitions.  Other standards, or even projects or individuals,
can use their own less-well-known or even private xtypes, but may
not be able to rely on general purpose software to do anything
clever when they encouter them.  Such less-well-known xtypes
do not "make VOTable unimplementable" or otherwise impact
on the implementability of VOTable itself.

Having said that:

> All other xtypes are gratuitous and should go.  This concerns 
> 
> * ID's xtype="ivoident"
> * POL's xtype="Stokes" (or "stokes"; the draft proposes both)
> 
> These serve no purpose I can discern.  What would clients do with
> them?  Instead, they just pose traps into which services will fall
> when they're validated -- services that otherwise perfectly work.

I basically agree with this as far as most of the xtypes in the
SODA WD go.  Unless there is some obvious work for them to do,
I don't think it's a good idea to proliferate new xtypes.

> They'll also be points of confusion when implementors ask themselves
> what they should possibly to with these xtypes.  I solemnly proclaim
> that I won't be the one to stand up on the mailing lists and explain,
> they're not supposed to do anything to VO newcomers.

(Parenthetically: I have no objection to doing that standing-up-
and-explaining.  For the reasons I've outlined above I think it's
defensible, and I doubt if VO newcomers who've waded through the
UCDs and Utypes will be very upset to find another attribute they
are allowed to ignore.)

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/