[TAP] Summary: data type for column metadata

[Markus Demleitner]

On Wed, Apr 15, 2009 at 10:16:26AM -0700, Patrick Dowler wrote:
> 1. use ADQL datatypes rather than VOTable datatypes:
+1 from me.

> sizes. It was also not clear if we need to include CLOB and BLOB now. No one 
> mentioned any real use/desire to have DATE or TIME.
...except that I think we should allow some way of saying "other".
Real DB tables may have columns in them built on DB-local types
(like, TIME, or weird things).  I think we need to say how to expose
them or not to expose them, i.e., either

Columns with types not in the above list MUST have NULL [or
whatever] here.

or


Columns with types not in the above list MUST NOT be listed in the
TAP schema.

> 2. add single additional optional metadata coordinate system spec, with values 
> coming from tables in STC, FITS, and a few in TAP directly to fill gaps (with 
> intention to deprecate them when a definitive source is written: eg Time WCS 
> paper and/or another rev of STC). Several values could be put together with 
> dashes (as in STC Lib); someone could could plausibly (outside TAP spec) 
> extend STC Lib with more useful constants so there is a nice picklist (and 
> thus also used in the VOTable output, so this approach largely solves result 
> metadata as well).
I still don't like it and would still maintain this kind of
information should come from a query for an empty VOTable, since the TAP
schema simply cannot carry useful information in the general case;
most importantly, you would have to provide some grouping mechanism
so people could assemble the "right" values to coordinate pairs, or
you gain nothing by the inclusion of STC metadata.

If you go ahead and mandate the STC alphabet soup in the TAP schema,
at least add a sentinel value "Not expressible in alphabet soup, see
VOTable".  There are tables that have coordinates for equinox
1875.0...  How one can fix the lack of grouping without adding more
tables or doing weird hacks I don't know, though.

Cheers,

         Markus