Hi Again -
> +VOQL-TEG-1/AI#7 on FO (plus DT/KA): to propose a mechanism for getting
> table metadata within the TAP and possible output format
Without proposing a specific mechanism, to follow up on the discussion we had in the last telecon here are some thoughts on this matter:
o We agreed in the meeting that it must be possible to query
table metadata directly via a TAP service. If an application
wants to cache this information (be it in a registry or
elsewhere) that is fine, but this is an independent matter
and not the concern of TAP.
o A table metadata query is very similar to a table data query.
A table metadata query returns, for example, a list of tables
with metadata describing each; for a single table, a list of
table fields with metadata describing each, and so forth -
the output is a table, just as for a data query, except for
the fields of the table, which for metadata queries would be
defined by the interface.
This is different than the case of getCapabilities, which
returns structured metadata of various kinds all in one
document, rather than a simple table.
o The two options discussed in the meeting for returning table
metadata are to return the table data in native XML, or in
a VOTable. Native XML is easier for XML tools to parse and
is more consistent with getCapabilities and the registry.
However, since what is being returned is a table, why not just
use VOTable so that we can reuse the same interface that we
use for table data queries? Client applications will want to
do table metadata queries as well as data queries, and if we
use VOTable, the same interface and much of the same client
implementation could be used for both.
o Regarding how to perform such queries, it could be done 1)
as in SQL 92 using the query mechanism to query a metadata
table with a SELECT expression, or 2) with one or more
dedicated table metadata query operations. Since for TAP we
probably don't need a fully general query mechanism for table
metadata, 2) might be the better option. It would be
nice to minimize the number of such operations and hence the
overall size of the interface; perhaps one table metadata
query operation with parameters specifying what to query,
could provide what is needed.
This would appear to be a core operation which any general TAP interface ought to support.
If we were to eventually use TAP as the basis for the other DAL interfaces this could also be a useful operation, and could be used for example to query the service for the fields of the query response VOTable it would return in response to (for example) an SIA V2 queryData operation. This could identify which standard fields of the query response are supported by the service, as well as identify any custom fields added by the service. To what extent this might overlap with getCapabilities (for the DAL interfaces other than TAP) is not yet clear.