SODA gripes (2): Gratuitous xtypes

[Patrick Dowler]

The WD-DALI-1.1 (diffs:
https://volute.g-vo.org/viewvc/volute/trunk/projects/dal/DALI/DALI.tex?r1=3117&r2=3135)
defines xtypes for timestamp, interval, point, circle, and polygon.
Timestamps are defined as char and the others are defined as arrays of
double and values do not include the shape.


There is a TODO/question about whether we should specify the coordinate
"range" construct and/or the STC "box" concept... the only real use cases
are that they can be more convenient than polygon but they don't enable any
new functionality.

I agree that we do not need xtypes for identifiers (at most, you might want
to say that the char* value is a URI and can be parsed as such) and
certainly not for polarization states. That's more like an enum or a
vocabulary...

Given that DALI-1.1 defines the needed xtypes (and it is in DALI because we
want consistency across multiple services) I agree that SODA doesn't need
to define any xtypes at this time.

On Wed, Jan 20, 2016 at 2:43 AM, Mark Taylor <M.B.Taylor at bristol.ac.uk>
wrote:

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



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20160122/13ba7bab/attachment.html>