On Thu, 17 May 2007, Guy Rixon wrote:
> On Wed, 16 May 2007, Doug Tody wrote:
>
> > I think it could help advance the TAP discussions enormously if we could
> > reach agreement on the following key issues:
> >
> > [...]
> >
> > Since both table data and table metadata are tabular, it is possible
> > to use the the same mechanism to query both. This simplifies things
> > for the client and will promote code-sharing at all levels, plus it
> > is more flexible if we wish to describe more than just tables/columns
> > in the future (e.g., views, indexes, etc.).
> >
> > ** Do we provide a uniform interface for table data and table metadata
> > queries?
>
> It doesn't simplify anything for clients that read VOResource.
As I said in yesterday's meeting, I think we can support this use-case easily no matter what TAP looks like, and registry issues should not drive the TAP design.
> If you want to simplify matters by using _existing_, commodity code
> for parsing metadata, then you must use only the VOTable header and
> not the rows of the table to carry those metadata. Specifically,
> you have to emit the same VOTable as you would for a data query,
> omitting the rows. Anythign else would need to be specially written for
> TAP. If you keep the commonality, which is fine, then you can't have
> the extensibility too. If you think that you can describe any view or
> index as a kind of table then you could do that with VODataService too.
Well this is not what is proposed. If SCHEMA.columns is a table of columns describing all the columns in all the tables in the database or tableset (which is the information_schema model), and it is returned as a VOTable, the data rows will contain the metadata for the tableset columns, one row per tableset "column". Hence the metadata comes back to the client app as data, just as if a data table were queried. VOTable is merely a standard table container and data format. XML, CSV etc. could alternatively be used to return the same information. This is uniform and simple, and also avoids the unnecessary coupling of a database schema with a VOTable schema.