datatype values in TAP_SCHEMA.columns

[Patrick Dowler]

Hmmm. I think this refers to the statement that mappings are defined in 
section 2.5, and in there a table gives some values for the VOTable 
xtype and TAP_SCHEMA.columns datatype ... some values.

I take it that the "non-prefix" argument is that the last column 
"database column type" is specifying what goes in TAP_SCHEMA, but there 
is some evidence that that is not intended. First, I don't think anyone 
would put "CHAR(n)" as the datatype in the TAP_SCHEMA (or the other 
explanatory values). I especially don' think one could claim that 
boolean is supported, but has to be called "Not supported" in the 
TAP_SCHEMA :-) These were intended to just be RDBMS type language for 
implementers to refer to.

As for the second column, it only specifies a handful of adql:<type> 
values in the ambiguous cases, which make sense in the context of xtype 
and table uploads. The heading says that these values go into both xtype 
and TAP_SCHEMA, which argues that the prefixes are intended to be used 
in TAP_SCHEMA. However, the large number of blanks (blank here to 
indicate that xtype is not needed for most datatypes in an uploaded 
table) is not supposed to imply that TAP_SCHEMA.columns.datatype is 
blank :-) I think the trouble came from trying to have one section/table 
describe uploaded tables and the mapping and the datatypes in TAP_SCHEMA 
- largely the same but with some subtle differences (namely xtype being 
optional in most cases) - and cramming two things into one column.

So that looks like a mess. The prefixes definitely go into the xtype 
attribute and the VOSI-tables output. Whether the spec says they do or 
don't go into the TAP_SCHEMA depends somewhat on which of the above 
vague and inconsistent sections you believe. IIRC, the intent is that 
they do go in, which is why our service is using non-standard prefixes I 
got from VODataService (next message :-)

Pat

On 04/06/14 02:37 AM, Mark Taylor wrote:
> My reading of TAP sec 2.6.3 is that the non-namespacers are right,
> Those in the other camp include GAVO, CADC and ASDC.
> I've talked to Markus, and he agrees that he appears to be
> doing it wrong.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)