New version of VO Support Interfaces: v0.26

[Doug Tody]

Hi Guy, All -

I just wanted to mention that the issue of getCapabilities as used in
the DAL services continues to be hotly debated.  The main issue is
one of scope; should getCapabilities return only essential service
metadata describing the service instance (service capabilities
and limitations, interface, etc.), as opposed to returning a full
registry-compatible VOResource.

The problem is that a full VOResource can contain considerable
information which has nothing to do with the basic functioning of the
service, e.g., general resource metadata describing curation, content,
coverage, etc., and it is a burden to ask service implementors to
provide and maintain this information at the level of each service
instance, particularly when much better tools for entering and
verifying this high level information may already exist in registry
portals.  Information which really is specific to the service however,
such as the service metadata defined in the service specification,
fundamental limitations, which optional capabilities are implemented,
the service interface including input parameters etc. (basically
what is in the Capability element of the VOResource for a service),
should clearly come from the service since the service is the ultimate
source of information about its capabilities.

The key issue we need to decide here is what needs to come from the
service instance itself, and what can be provided elsewhere, e.g.,
by the registration process.  Otherwise it is likely nothing will
actually come from the service - people are more likely to manually
enter the information into a registry portal, and download and "cache"
the resultant VOResource document in the service.  A more workable
scheme may be to have only information which the service directly
manages come from the service, and merge this into the overall resource
record maintained by the registry.

 	- Doug


On Mon, 7 May 2007, Guy Rixon wrote:

> Hi,
>
> in view of the cross-WG debate on getting metadata from services, I have 
> produced a new version of the VO Support Interfaces spec, which you may find 
> at
>
> http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupportInterfacesMandatory-0.26.pdf
>
> In this version I've tried to make the operations compatible with the 
> suggested equivalents in DAL and TAP.
>
> The operation that produces VOResources is split into getRegistration - that 
> which the service author wishes to put in the registry - and getMetadata - 
> all the resources, including those that should not be registered. This tries 
> to cover the cases of volatile metadata which change too often for the 
> registry to keep up.
>
> The use of VOSI in REST systems is emphasized. In particular, in a REST 
> system, the getMetadata and getRegistration operations can be implemented as 
> any (HTTP) endpoint that produces the right kind of document. Therefore, the 
> author of a DAL service might register, e.g., 
> http://my.server.edu/dal-service/getCapabilities?FORMAT=VOTable, calling out 
> a specific use of the DAL getCapabilities operation. Further, the 
> registrationChangedOn and metadataChangedOn operations for a REST service are 
> now just the normal HTTP headers for the registration and metadata documents; 
> no need to implement extra operations and so less work.
>
> I've de-emphasized the SOAP binding for VOSI, but it's still in there, 
> unchanged from v0.25.
>
> Normally, I'd suggest these changes on the GWS list before posting a new 
> draft. Since we're so close to the Interop, I've taken the liberty of posting 
> it anyway. It would be really nice to wrap up VOSI in Beijing.
>
> Cheers,
> Guy