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