New version of VO Support Interfaces: v0.26

[Doug Tody]

On Tue, 8 May 2007, Tony Linde wrote:

> That makes sense to me, Doug - thanks.
>
> I'm not sure what proportion of services would be managed in this way but
> I'd be surprised if the major ones weren't. That said, I'm sure you'd agree
> that other services might not have this separation of concerns.
>
> So, we've got:
> a) all metadata maintained via registry UI;
> b) resource metadata maintained by registry UI and service metadata sourced
> from service (using your terminology);
> c) all metadata sourced from service.
>
> Questions (to ALL):
> 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?

My opinion is we don't need a) except for the general resource
metadata; c) is going too far and probably won't even work in
some cases (e.g., there is no service available for many classes
of resource).

> 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?

I think it has already been done.  The VOResource Capability element
is the service metadata.

For getCapabilities, what Ray and I discussed just in the past day
or so in private email was having the service define the Capability
element (as is the current plan for registry), but what getCapabilities
would return is not a VOResource, but some service-defined simple
getCapability container schema containing the Capability element.
When updating a service's capabilities, the registry would just extract
the Capability element and replace the cached version with the new one.
Any other information would be discarded.

 	- Doug


> 3. if all three options are supported, how does each resource indicate which
> option it has taken?
> 3a. should VOSI include (optional) getResourceMetadata and
> getServiceMetadata methods (or cgi urls)?
> 4. any other questions?