Keith.
-- Keith Noddle Phone: +44 (0)116 223 1894 AstroGrid Project manager Fax: +44 (0)116 252 3311 Dept of Physics & Astronomy Mobile: +44 (0)7721 926 461 University of Leicester Email: ktn-at-star.le.ac.uk Leicester, UK LE1 7RH Web: http://www.astrogrid.orgReceived on 2007-10-03Z17:49:44attached mail follows:
Hi Guys - On Mon, 1 Oct 2007, Francois Ochsenbein wrote:
> Anyway, it is useful for the presentation of table metadata -- but for
> queries, I don't see a priori why this organisation would be superior to
> a query to an XML database containing a concatenation of all VOTables
> contained in a server. Isn't it the way registry records are organized ?
I have been on travel for a couple of days and will try to catch up on this discussion tomorrow. In the meantime: Francois, the simple answer to your question is that the IS approach is better because it is simple, extensible, and uses the _same_ interface used to query table data; all we do is query SCHEMA.columns (or whatever) and immediately we see the table metadata using the standard query interface, with nothing else required. Using the votable-header approach we have to use a VOTable library to get at this information; in a high level client interface we may not see VOTable at all - my VOClient code for example implements a JDBC type interface which hides how the table data is serialized, so what we have looks like an ordinary database query. Normally the client app never sees a VOTable. Using VOTable headers to pass metadata but VOTable to pass data is inconsistent. The IS approach on the other hand works no matter what format is used to pass back table data; it would work with CSV, XML, FITS etc. as well as VOTable. The VOTable header approach does not extend to including any DBMS metadata other than that supported by the VOTable model, and it is inefficient if the DBMS contains many tables. With the IS approach it is trivial to get a listing of the tables in the database; with the VOTable-header approach we have to use a VOTable library to scan the TABLE elements in a VOTable to reconstruct this information. I think it is bogus to look only at the VOTables used to pass back this information. A client application does not normally see the VOTables, it sees the _information content_ of the VOTables (or whatever serialization is used). In a table-oriented interface it should be possible to print this information as a simple table. The chief problems with the VOTable-header approach are as follows: - A different interface/approach is required for querying table data and metadata; we do not provide a uniform interface. - It is limited to only describing tables and columns, using only the VOTable model; it does not extend to describing DBMS information required for advanced queries for example. This is extremely limiting. If we start with this approach and later try to do anything different such as IS, we have a major interface change. - The mechanism is too VOTable specific for a general table access interface. In principle TAP does not require VOTable, and VOTable is only a serialization. I think it would be a big mistake to implement something in TAP 1.0 which we already know does not meet our requirements for a general table interface. - Doug