table metadata and the registry

[Doug Tody]

Hi Tony -

This is more than just a registry issue, hence I will comment as well.

We have had extensive discussion of this issue in the context of TAP.
While it is not yet clear if a consensus has yet been reached, it seems
preferable to have a custom interface to query database/table metadata.

This can be voluminous, e.g. for a service which provides access to
many tables, or where tables may have hundreds of columns.  Also, it
is not yet clear what database/table metadata needs to be returned to
support query building for certain classes of queries (in the general
case, especially with multi-table operations on large tables, some
additional elements of the SQL information_schema may be required,
e.g., information on indexes and views).

This is data-related metadata, and in general access to such metadata
is as important as access to the data iself, hence it is convienient
to be able to query it directly, ideally (from the perspective of a
client application) with an interface similar to that used to query
or access the data itself.

The above is the main reason for a separate interface, but this will
greatly simplify "getCapabilities" as well, as then all it has to return
is the actual service metadata, i.e., service capabilities, limitations,
optional features implemented, interface, etc.

	- Doug


On Wed, 9 May 2007, Tony Linde wrote:

> Hi Ray,
> 
> I was out today - that's why it has been so quiet :)  Only, joking: I agree
> it is winding down.
> 
> Just one point I wanted to clarify: I sensed you were proposing the
> table/column retrieval method as 'extra' to the getCapability method. If
> not, no problem, discussion over. If so, can you explain why we'd need both?
> 
> Cheers,
> Tony.