Hi all,
> But this is exactly the approach already adopted for the other DAL
> services, which I think Ray and I agreed to. A service should be
> self describing; the getCapabilities operation is the fundamental
> source of information regarding the capabilities of the service.
> The Registry itself, given a service endpoint, uses this to query the
> service metadata, which is merely cached in the registry. The cached
> information in the registry is used for service discovery, but a client
> can query either the registry or the service for service metadata.
> Hence a service can function with or without a connection to the registry
> (as in Kona'a example of an unregistered scratch service).
Speaking personally, I am agnostic about whether tabular metadata ought to be stored in the registry (fine-grained registry) or available only from the service (coarse-grained registry).
As I see it, as long as we can get tabular metadata from the registry or from the service *in a common format* (i.e. some sort of vo-resource xml / xml fragment), then it doesn't matter so much where that metadata comes from. Fine-grained and coarse-grained registries can co-exist happily in such an environment, and the client tooling doesn't have to become overly specialised to either case.
All best,
Kona.
-- Kona Andrews kea-at-roe.ac.uk AstroGrid Project http://www.astrogrid.org IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJReceived on 2007-03-08Z14:41:03