TAP document implementation issues. Section 2.6

Tom McGlynn Thomas.A.McGlynn at nasa.gov
Tue Sep 29 05:32:24 PDT 2009


Recently the HEASARC began an effort to create a new basic query service 
for its catalogs.  As part of that we'll be implementing the TAP 
protocol.  As we implement features I'll be posting questions and issues
we have with regard to the TAP document from the perspective of someone
trying to implement it.  This will be in the order of implementation, 
and will presumably skip around the document.  We started by 
implementing the metadata described in 2.6.  Questions are as they came 
up, not any order of importance.

	Tom


1. Why is the schema name given as both a separate
column and part of the table name in TAP_SCHEMA.tables?  Is the schema
supposed to be repeated both places?

2. Confirm that schema queries are case insensitive.  The use of caps 
for the schema name and lowercase for the table names tends to suggest
that case is significant.

3.  If all fields are strings, what are the correct
values for tables.std, tables.primary, tables.indexed
to indicate that the value is set or unset.  Might be better
if these were boolean.

4. Is TAP_SCHEMA.keys required to include a row for
itself and TAP_SCHEMA.key_columns?  By the by...  How is a Many-Many 
joinintended to be rendered?  This requires an intermediate table.  Are
there to be two joins described. If so how is the relationship of these 
two joins conveyed to the user?

5. Are there any maximum lengths for the size of a schema name,
table name, column name?  Is there a required minimum length that needs
to be supportable?  Is this information available to the user?
Do we need to provide information like this to the user somehow.
[Java's JDBC has a vast framework for this kind of information
but we do nothing in TAP.]  This is jumping ahead, but what is supposed 
to happen if a user tries to create a table or column with a name that
exceeds the local maximum?

6. Is columns.size really supposed to be a string rather than an int?
Is there any limit?  Can we support variable length without
a defined max (e.g., text)?  What value should this for non arrays?  Null?

7. Don't have a clue what 'standard' means in the context of the
schema (i.e., for the last column in TAP_SCHEMA.columns).

8. Table in 2.5 suggests that VOTable Char without an array size
should map to varchar in ADQL.  Is that a typo where
the '*' is missing in the array size?  I'd think a VOTable
without any array size should presumably map to a char (or char1)
in ADQL.

9. In 2.6 the table in 2.5 is referred to as defining the ADQL types 
available, but this is not how the table is described in 2.5 where it 
gives the mapping from VOTable types to ADQL types.  If it is intended 
to explicitly enumerate all of the types available to a TAP table, then 
this should be stated much more explicitly.  In that case the table is 
backwards. It should have the ADQL types as the first column, not the 
last!  Also, such a critical table cannot be placed in an optional part 
of the specification! Presumably it should really refer to some 
appropriate table in the ADQL document. I think it would be fine to copy 
that into this docuemnt and label it as such.



More information about the dal mailing list