TAP information schema

[Doug Tody]

Hi Ray -

The intent of specifying what is "required" was to require only things
which are available from any DBMS, without requiring the data provider to
modify or extend their tables.  If we were using the metadata to instead
describe a data service (SSA etc.), where different metadata is required,
one might choose to make a different set of things required.  (If later
we integrate table metadata queries into services we should probably do
just that).

This does make things more difficult for the client however, and could
lead to query failure if we were to try to use something like ADQL
(as an advanced capability) to query such metadata.  As you suggest
it might be better to make all defined elements of the IS required,
and just allow most elements to be nil-able or have defined defaults.
Then queries would be more straightforward, and it would still be easy
for a service to generate the information (we always have some service
software in front of whatever back-end is used, so it should be easy to
generate these tables).

	- Doug


On Fri, 5 Oct 2007, Ray Plante wrote:

> Hi Doug,
>
> I noticed that your schema marked some things as required; I take it that
> the other items are optional (always a reassuring notion).  I'm curious,
> though, how client knows what what columns are available for an IS query.
> Did you have a scenario in mind?
>
> Knowing nothing to start with, I can imagine that the client would send a
> trivial "select *" kind of query and then analyze the header (although
> this is not much different from analyzing a FORMAT=METADATA query ;-)
> Alternatively, the standard might instead make all columns required, but
> possibly empty.  The intent is that all possilbe would in practice be
> queriable and no initial meta-meta query would be necessary.
>
> cheers,
> Ray
>