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.
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
Received on 2007-05-07Z21:48:47