VOEvent 2 TABLE mechanism

[Douglas Tody]

Hi -

I was asked to take a look at the VOVent 2 draft, in particular the new
TABLE construct to see how well it would work for embedding externally
defined data model information (e.g. a simple time series) in a voevent
packet.

In general this looks good and is probably adequate for the simple cases
it is intended for - for more complex cases one could presumably just
use a "reference" to an external dataset.  Semantically it is very
similar to VOTable hence the mapping should be straightforward in most
cases.  UTYPE allows data models to be represented in any variety of
ways without loss of information so the content of a data instance
expressed in a votable (or in FITS or whatever) should map into the
voevent table representation without loss of information.

A voevent table element can contain both PARAM and FIELD and these have
a uniform set of metadata elements as in votable (name, datatype, unit,
ucd, utype).  This is all that is really needed in most cases.  The main
thing missing is GROUP.  In votable this is most commonly used to group
the elements (fields or params) of a component (small) data model.  This
can be used for example if there are multiple instances of a small data
model in a table (photometry band definitions for example) and we need
to distinguish them.  However there are other ways to handle this and it
doesn't come up very often.

So VOEvent 2 does look like a good compromise to provide both a fixed
schema for the essential voevent bits, as well as a general container
mechanism (param, table) for extending the model without having to
change the core schema.

 	- Doug