New version of VO Support Interfaces: v0.26

[Ray Plante]

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