getCapabilities

[Doug Tody]

On Tue, 1 May 2007, Patrick Dowler wrote:

(Sorry, I can't include your text without overrunning the 1-page limit.)

> The topic of getCapabilties has come up and I for one am rather
> unclear about what is included in it. My reading of other specs
> and emails in DAL suggest that it is about whether or not a service
> supports optional ** methods **. I also recall it is the place to
> declare what version(s) of a protocol is/are supported.

It is not just methods.  The basic concept is that getCapabilities
returns the service metadata, which describes the service itself.
This includes the service interface version(s) implemented, with a
separate description if multiple interface protocols are provided
(e.g., HTTP and SOAP), specific service interface capabilities
such as a list of any extra input parameters the service supports,
what protocol features the service does and does not implement (the
service capabilities), etc.  It should also list the data collections
which the service provides access to, with the actual description of
a reference collection stored in the registry.

Since the service gets to define its own service metadata for the
registry, and the scope outlined above is very similar to a VOResource,
this is probably the same as a VOResource (which is what the Registry
guys want us to do).  If VOResource is too complex we could do something
simpler, but probably we should just have getCapabilities return a 
VOResource document.


> So it may be applicable for describing whether a TAP service supports
> sync and/or async query methods (for example) but it does not look to
> me like it would be the place to describe the content model of the
> service (eg.  database, table, and column metadata in TAP) nor does
> it look like the place to describe support for non-mandatory parts of
> the ADQL language (for example, UDFs). I am not sure about the latter,
> but to me ADQL is "input content" and not "service API".

Correct - database (tableset) and dataset/table metadata is not service
metadata, and would be described elsewhere, in a database/table metadata
query of some sort.  ADQL features such as the ADQL version(s) supported,
optional UDFs, etc., *could* be part of the service metadata, as these
are service capabilities (something like UDFs could also be described by
a TAP version of the information schema).


> Does typical DAL getCapabilities() include a method to get the
> registration (the VOResource)? Maybe that's the thing I missed that
> is the source of contention between it and TAP metadata...

In the current proposal, getCapabilities *generates* an XML document
(VOResource) describing the service capabilities.  This could then be
cached in the registry or used directly by the client.  (Simple clients
probably would never need to look at the service metadata as service
discovery via the registry will be sufficient).


> I recall that it also includes a declaration of protocol versions. In
> SSA, does that include the version of the spectral model? If so,
> then a TAP capability may well include declaring the presence of
> and version of a data model describing the content (which IMO should
> imply that the service supports querying by utype, since that's the
> whole point of saying which model describes the content.. a la Source
> Catalogue Data Model effort).

In SSA, the version of the SSA protocol and the version of the Spectrum
model are linked; a given SSA protocol version uses a specific version
of the Spectrum model.  This is because the protocol uses the data model,
so we can't easily separate the two.

For TAP the same thing would hold, e.g., TAP X.Y would use a specific
version of the Catalog DM.

 	- Doug