On Tue, 24 Apr 2007, Francois Ochsenbein wrote:
> 1. Questions of vocabulary
>
> It is fundamental in the discussions to ensure that we are sharing a
> common vocabulary. Tables, columns, catalogs, databases, (primary) datasets,
> (virtual) tablesets, protocol ... seem to have varying meanings.
> All these terms ought to be defined rigourously in the final document.
> Would this be possible ?
The SSAP doc for example has a "terminology" section at the front; we should do the same for TAP (and be consistent of course). This is all part of the model which the protocol implements, and will carry all the way into future applications, hence it is quite important.
> 2. The role of the protocol(s)
>
> Assuming that the protocol represents the dialog which takes place
> between the application (client) and the data provider (server),
> we have to distinguish clearly the roles of the connection layer
> (HTTP or SOAP) from our protocol (the TAP). These should remain
> as independant as possible -- or we would have to reconsider TAP
> if we move to another connection protocol. Therefore using HTTP-
> specific codes to indicate an empty result does not seem to be a
> good approach for me.
This is essential. The applications protocol we are defining is TAP; HTTP is used as a transport protocol, but other transports could be used in the future. A single service instance could also support multiple transport protocols (there was a related discussion of this recently in the apps messaging discussions). Hence
o A query which finds nothing should return a VOTable (or
whatever) with zero rows, and this is not an error.
o The output format should be specified at the TAP level, rather
than using HTTP (an example where HTTP might be used is in
enabling transport-level compression which is transparent to
the client).
o How to return errors should be defined by the high level
protocol: for SSAP we use a VOTable INFO, as for SIA V1.0,
and advise clients to also be prepared to deal with an
HTTP error code if some more fundamental error occurs.
We considered using native XML for the error response, but
decided to stick with VOTable for consistency, and because
a VOTable containing only status information is about as simple
as any alternative small XML entity.
> 3. DAL commonalities
>
> Yes, having similar basic methods for accessing VO data is desirable,
> for instance having the "queryData" and "getData" -- which I see as
> a way of asking "how should I formulate my request" and "this is my
> request" -- introduces a flexibility which looks fundamental. However
> from Doug's document I could not get a clear idea on how to get only
> metadata (i.e. detailed description of the tabular material involved) ?
> Looks like "queryData" can return full results or just table descriptions
> -- who decides (client or server) and on which grounds ?
See the examples of how it might work included in the mail I just posted earlier today. The client specifies what it wants to receive.
> I would also like to be sure that tabular data which are not of the
> "astronomical catalog" type (e.g. atomic data) are not forgotten in
> this approach.
This data would still be supported, but some of the dataset metadata (Char) and model-based query parameters (POS,SIZE, etc.) would not be defined for such data. However, one could still query for the table columns, and query the data directly with ADQL. Perhaps we need some sort of keyword or UCD search capability to help support discovery of such tables.