datatypes (effects all 3 WDs to some extent)

[Mark Taylor]

Pat et al.,

On Wed, 19 Mar 2014, Patrick Dowler wrote:

> Summary: ad-hoc datatypes used in parameters cannot currently be described
> using VOTable PARAM elements. We need to either:
> 
> #1 temporarily use ad-hoc datatypes anyway, describe with the xtype
> work-around provided, eventually formally define the datatypes and make them
> fully supported in VOTable, OR
> 
> #2 don't use ad-hoc datatypes and stick with what can be described now

I agree that there is a problem here that needs some kind of policy
or action.

I share Pat's vague sense of unease with the idea of doing
everything with MAX/MIN or similar, on the same grounds that it
feels like it might turn out to be badly underpowered for something
we need to do at some point.  On the other hand not having to
define new data types and associated syntaxes would be a whole
lot better if we can get away with it.  My pragmatic side inclines
towards #2 (no new datatypes -
http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
but I don't feel sufficiently immersed in the use cases to have
a firm opinion on the right way to go.

However I do have some comments/queries about the role of VOTable in this.

> Ideally, we would have a document that defines datatypes and serialised
> values. Then ADQL-2.x would refer to that document, VOTable-1.x (x>3) would
> need to support serialisation of values of those datatypes. TAP-1.x would not
> have to say as much about datatypes as it does now, so it would get stripped
> down a bit. Other DAL and DM documents could use the datatypes by reference to
> a definitive document.

I'm not sure exactly what you have in mind for the future extensions to
VOTable here - your use of the term "datatype" suggests that you are
proposing new primitive values of the datatype attribute alongside
"boolean", "int", "float", "double" et al.  I would personally be
unenthusiastic about that for the two related reasons:

  (a) the other datatypes are primitive values, and something
      like interval doesn't seem at the same storage level, and

  (b) it means that every time we need a new datatype it means a
      revision of VOTable (and updates of generic VOTable parsing
      software libraries etc)

My view of VOTable is infrastructure that should be capable of
storing syntactically or semantically complex content without itself
being syntactically or semantically complex.

*If* we are going to encode more or less complex data types in
VOTable I think that the xtype hack is the right way to do it.
So then instead of requiring VOTable-1.x (x>3) in the above scheme
you'd use VOTable in substantially its current form, but have
an additional document (it could be something freestanding or sections
of one or more existing or upcoming standards) that defines how to
encode (e.g.) interval values in existing VOTable primitive fields,
marked by given xtype values.  General purpose VOTable libraries
might or might not provide support for these types depending on
their target clients, but it wouldn't be part of the VOTable core
standard as such.

I don't claim any definitive view on the future of VOTable, that's
just my feelings.

In connection with another issue, I've just started a new wiki page

   http://wiki.ivoa.net/twiki/bin/view/IVOA/VOTableIssues13

as a placeholder for things that might need to get addressed in
future versions of VOTable.  If you (Pat/Markus/list) think there
is or may be something here which should get addressed in a future
version of the VOTable standard, I encourage you to add a section
(though by all means wait until it's clear from list discussions
what it should contain).

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/