[TAP] Summary: data type for column metadata

[Gerard]

> 1. use ADQL datatypes rather than VOTable datatypes:
> 
> BOOLEAN, SMALLINT, INTEGER, BIGINT,
> REAL, DOUBLE,
> TIMESTAMP,
> VARCHAR, VARBINARY,
> POINT, REGION
> 
> It is not clear if we need the fixed-size types (char, 
> binary) and to know the 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.
>  
I am in favour of this.

Re CLOB and BLOB. Would a distinction with varchar and varbinary
respectively be useful for the query writer? 
If not they could be left out, assuming that also their serialisation in a
result would be the same as those var-types (respectively)?


> 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 am not very enthousiastic about this. Can we really not leave it out and
for the time being leave it up to users to read the details of a given TAP
service's schema? Imho TAP is too low-level to support the kind of automated
interoperability  that seems to be foreseen in some of the use cases. For
example, I don't see a place in TAP to indicate that I am storing images in
one table, a source catalogue in another (whatever their coordinates) which
would lead a tool to infer that results can be over plotted irrespective of
the way to specify coordinate systems.
I think I agree with Markus also that one would need a votable-like
structure with groups etc to do this "properly".
But I do NOT advocate that we follow that route here.
Really it seems to me that this type of specialised semantic information
more properly belongs to standard data models that choose to use TAP for
their access protocol. For example SSA, SIA or the to be completed source
data model could add this type of metadata and provide it with the required
amount of detail.

> 
> PS-If everyone thought this was fun, the next email is on the 
> more complex metadata issues :-)
Finally !


Gerard