getCapabilities() for standard services

[Doug Tody]

Hi Ray, All -

Thanks very much for this review of our discussions of getCapabilities
and service metadata, from the Registry perspective.  This is a very
good summary of the issues.  I encourage others to comment, but for myself
I agree with essentially all of this.  If I don't comment on a point
that means I agree.

> We know it is not trivial for an end publisher to create VOResource records: 
> a tool is needed to create them, and a tool is needed to check them (and a 
> person is needed to make sure they make sense!).  These tools are not cheap 
> to create; nevertheless we have built them:  the first one is the resource 
> registration page that is part of each public registry, and the second one is 
> a validater that I have just deployed.
>
> OBS #2:  If we make service providers serve their own VOResource
>  record, the easiest way to provide them with the authoring and checking
>  tools is to provide a "download" VOResource button on our registration
>  pages.
>
> OBS #3:  If someone provides other tools that provide these functions,
>  that is no problem for registries.

There is also the related issue of service validation.  Both of
these issues - service validation, and service metadata validation -
concern both the registry, and those who specify the service (DAL in
this case).  Ideally what we would like to have are some Web-based
tools, which a service developer can run, *while they are developing
the service and before it is registered*.  My view is that probably
these should be developed by the folks that specify the service (or
perhaps people working closely with them), as part of the process
of developing a new service.  By the time a service reaches V1.0 and
is available for general implementation, we would like to have such
tools available to developers.

The issue of getCapabilities and service metadata is hence merely a
part of a larger problem of service validation.  It comes up during
service development, during service registration, and during the lifetime
of a service, as we will probably want to periodically verify that
services are still functioning correctly, and track any changes which
occur.

For these reasons I tend to see this information being entered
and maintained as part of service development.  Just entering this
information once, manually, in a registry form is not sufficient.
Ultimately, if service developers use standard service frameworks to
develop their services, it may be possible to automate and simplify
this process even further.


> Many people for a long time have argued that services should be 
> self-describing, the two main reasons being:
>  a.  The descriptions are more likely to be kept up to date if they are
>       served by the service itself.
>  b.  Clients can adapt their usage of the service by looking at its
>       capabilities first.
>
> OBS #4:  If services are self-describing, the process of registration
>    becomes simpler, only because the publisher has already paid the price
>    of describing the capabilities.

See above.

> OBS #8:  Client capability negotiation is a new thing in the VO; we
>   currently have have no (little?) software/experience making use of it.

Not true; this has been done for some time.  A good example of this is
the TSAP (theory-SSAP) "prototype" from ESAC (Pedro et. al., please
correct me if I get any of this wrong).  In this case, the client
application dynamically queries the service for its service metadata
(using FORMAT=metadata in this older SIAP-based implementation),
and dynamically adjust the GUI presented to the user, so that they
can input the parameters of a specific theoretical spectral model.
There are potentially many cases like this, and it is a good example
of why clients need access to this sort of information, post-discovery
of the service.

> OBS #7:  if getCapabilities() is essentially about returning a VOResource
>   document, then it is essentially identical to the getMetadata() that
>   was proposed by GWS as part of the support services standard.

Certainly.  The interesting thing here, is that both GWS and DAL
independently decided that it was usefulf for the service itself to
be able to return service metadata.  (The difference in the name of
the operation doesn't matter here; getCapabilities was chosen for
consistency with OpenGIS, which the second generation DAL services
are based upon, and because it is more descriptive).

> One way we discussed deploying the support services standard was as a set of 
> optional functionality added to a service.  We would encourage support for 
> the standard as a way of reaching a "gold" status.

This is an excellent strategy, and is a good way to deal with any
"recommended" or "optional" service capabilities.

> My own recommendation regarding getCapabilities() would be to spin it off as 
> an optional bit (a la the support services standard) that can be easily made 
> part of any DAL service.  This would allow us to go ahead and deploy it with 
> new services and get more experience using it.  We need time to
> develop support for it in the registry as well as in other client software. 
> In the future, new DAL specs could say "you MUST support the support services 
> spec vX.X".

This is actually much simpler than, for example, metadata mediation
or virtual data generation, so we should consider making it mandatory
(as FORMAT=metadata is in SIA V1.0).  However broader discussion on
this or any other point is welcome.

 	- Doug