New version of VO Support Interfaces: v0.26

[Tony Linde]

I think Doug raises a valid point and maybe in the future when registries
are being correctly populated, perhaps by automatic means, we can separate
the maintenance of different parts of the registry. I don't think it is
feasible at this stage though.

(Perhaps it isn't even desirable: the more we separate responsibility for
different elements of the registry record, the less likely anyone will do it
properly.)

> coverage, etc., and it is a burden to ask service implementors to
> provide and maintain this information at the level of each service

I cannot really agree with this. If the core information never changes, it
is relatively easy to enter it into a registry and copy the xml record out
to serve as a base template for the service's full VOResource record.
Depending on how these new service interfaces are coded, there'll be plenty
of other ways to ensure the information only has to be entered once. I
really don't think this is going to tax the interface developers much.

T.

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Doug
> Tody
> Sent: 07 May 2007 20:48
> To: Guy Rixon
> Cc: grid at ivoa.net; dal at ivoa.net
> Subject: Re: New version of VO Support Interfaces: v0.26
> 
> 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/VOSupportInter
> facesMandatory-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