TAP document implementation issues. Section 2.6

[Douglas Tody]

Hi Tom -

We have begun an implemenation of the TAP schema here at NRAO recently
as well, and ran into some of the same issues you mention.

Most of your comments probably only require clarification in the
specification so I will only address a few.

> 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?

The schema used in the fully qualified table name is that of the
native database - you provide whatever will uniquely identify the
table to the native DBMS if the given name is merely passed back.

The "schema" defined in the TAP metadata is a logical schema defined by
TAP and is used only to associate tables, not to construct table names.
Due to differences in DBMS implementations it might be implemented
as either a DBMS native schema or catalog; which is used is up to
the implementation.  We had to do this as DBMSes differ in whether
they provide catalog, schema, or both (all real DBMSes provide at
least one of these).

The client should preserve the case of the table name but whether or
not this matters depends upon the TAP implementation.  (In general the
case issues probably do need more explanation).

> 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.

In our (partial so far) implementation of the TAP schema here we
created DBMS tables much like TAP_SCHEMA.tables and TAP_SCHEMA.columns.
We did use boolean for std,primary,indexed in the native DBMS tables.
I agree we should consider just using boolean in the TAP schema itself.
This was an oversight I think.

We also still need to rename "primary".  I think Francois's suggestion
of changing this to "principal" is fine.

> 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).

Yes this is confusing (I assume you mean "std").  This is from
the registry metadata and is intended for things like DAL services
to identify which fields of the query response are defined by the
standard interface (and hence which are extensions defined by the
data provider).

This doesn't make a whole lot of sense for actual data tables,
but what we did here was assign std=false by default for all data
table columns.  Then if we have a field which is a standard field of
a data model (such as GDS), it would have std=true in direct analogy
to the registry SIA/SSA usage.  One could then do things like refine
a query to shown only the "standard" fields of a table.

> 1. Am I right that there are three ways to get metadata from a
> TAP services:
> 
> -- Direct query of TAP_SCHEMA starting with the required tables.
> -- Use of VOSI
> -- Querying database with known, non-TAP_SCHEMA tables but setting
> the maximum number of rows to 0 a la the Cone search.

Yes.

> 2. The TAP document does not provide enough information to write support
> fr the VOSI queries.  The VOSI document is also inadequate.
> 5. I'm lost as to what I need to do to support VOSI getCapabilities.  As 
> far as I can tell there's nothing that describes what the capabilities 
> record for a TAP service should look like.  Does it just reuse the

This is correct.  The TAP specification does not yet define the
Capabilities metadata.  This is a major omission but will have to
wait for the next version.  More prototyping is needed to understand
better what is optional (e.g. advanced ADQL functionality), before
we can fully define a standard Capabilities matrix for TAP.

> If I understand this properly then there is a very close relationship
> between the metadata tables parameters in TAP_SCHEMA and the XML
> requiredfor the VOSI table metadata query.  The TAP document should
> describe how the VOSI metadata query might be satified from the schema
> data.

It is supposed to be possible to auto-generate the VOSI table metadata
from the TAP_SCHEMA, e.g. if the implementation stores this metadata
in DBMS tables.  Not sure we really need to specify the transformation
though so long as both are fully specified.

 	- Doug