Doug
So long as the table metadata is available through queryData(), the TAP can be used effectively. Therefore we are good to go.
But the getCapabilities() function is, I gather, is to get the VOResource registry record for the service from the service itself rather than from the registry.
I wonder if we can make the getCapabilities() method optional, and/or put it into the next version of the TAP standard? The VO architecture puts the ultimate truth in the *registry*, not in the service; in this sense we are different from OpenGIS who do it the other way around.
Did something change when I wasn't looking? Is the registry now just a cache and the services have ultimate truth? When was this decided? Are cone-search implementors now forced into providing a getCapabilities() method?
Roy
> This ability to query table metadata, e.g., the list of tables and their
> properties, and the columns of an individual table, is an important
> feature
> of TAP, and is required to be able to query arbitrary data tables.
>
> getCapabilities on the other hand, is a separate service operation, used
> to return the service metadata, describing the capabilities of the
> service.
> Any client can use this information, but one very important one is the
> Registry, which will cache this information in a VOResource, so that
> clients can search for services based on their capabilities.
Received on 2007-04-25Z18:37:07