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).
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
>
Received on 2007-10-05Z17:26:42