Hi Tony,
On Tue, 8 May 2007, Tony Linde wrote:
> 1. can any of the above be knocked out: ie, knowing all the resources in
> your registry, can we exclude any of the above options?
> 2. how do we split up VOResource into resource and service metadata (Doug's
> terms)? I posed this in a previous reply to Ray: is it at the Capability
> element?
Yes.
> 3. if all three options are supported, how does each resource indicate which
> option it has taken?
The VOSI standard specifies that a resource indicates that it supports getRegistration() by including an instance of the VOSI standard capability. Thus, it is very easy to recognize case (c).
I'm not aware of a single way of identifying services that support getCapabilities(), case (b) as Doug has described it. At the moment, I think we would have to know which protocols are generation 2 DAL services. However, this metadata extension has not yet been defined, so we may be able to address this in a general way.
> 3a. should VOSI include (optional) getResourceMetadata and
> getServiceMetadata methods (or cgi urls)?
I don't see a need for getResourceMetadata(). getServiceMetadata(), I gather, is essententially what Doug wants for getCapabilities(). If we indeed have this latter one, then getRegistration() could use getCapability() to pull in the capability part.
> Question to Ray: does this cover your requirements, at least enough to
> discuss the above questions at Beijing or have I missed a major part of your
> proposal?
Well we will certainly discuss this in Beijing. I see the access to table metadata as orthogonal (though definitely related) to this discussion. In particular, while a registry may get the resource and/or the service metadata from the service, both parts are needed for a minimally complete description of a service (regardless of whether there are table metadata included explicitly or indirectly via a URL).
cheers,
Ray
Received on 2007-05-08Z23:42:21