On Wed, 16 May 2007, Doug Tody wrote:
> On Thu, 17 May 2007, Guy Rixon wrote:
>
> > 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.
OK, understood. I see how a SCHEMA meta-table would be used. But this is not an established solution in VO; we don't have complete applications that can read this stuff. If we do it this new way, we should do it because it is better, not because it is cheap to implement.
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523Received on 2007-05-17Z03:40:21