Hi Tony -
I got a bit behind in my email at the Interop and am just now catching up.
I agree with your statement below; a service should describe its capabilities and we want to use this information to (among other things) populate the service metadata in the registry. The issue is, is the schema for the output of the getCapabilities operation of a service defined by the service specification or by the registry?
My view is that this is a service-defined interface since this is a fundamental service operation and may be used for purposes other than populating service metadata in the registry, e.g., a client application may well query a service directly for its capabilities (for example we already have applications which do this with FORMAT=metadata in SIAP and SSAP, which getCapabilities is intended to replace). The intention would be to make the output semantically compatible with what the registry requires but there could be differences in format, content, or version, and it is possible that an automated transformation might be required to produce a resource specification in the exact format required by a given target registry version or implementation. The service specification should fully define the output required such that a service implementor can provide what is required without any knowledge of the registry or any other potential client application. We can ensure that registry requirements are satisfied separately at the time that the service specification is written, without need for service implementors to understand these requirements.
On Thu, 18 May 2006, Tony Linde wrote:
> This would be fine, Doug, if everyone agreed to fully populate the registry
> with the necessary information and keep it up to date but many service
> providers only want to register the minimum information and have the
> registry get the full set of information from the service. In this case
> services must know and provide the complete set of registry information. And
> since the registries cannot know which services are being fully registered
> or not, then every service will have to provide its own complete resource
> metadata information.
>
> T.
>
>> -----Original Message-----
>> From: Doug Tody [mailto:dtody-at-nrao.edu]
>> Sent: 18 May 2006 17:40
>> To: Tony Linde
>> Cc: voql-at-ivoa.net
>> Subject: RE: STAP is the protocol, Skynode and DSA are implementations
>>
>> On Thu, 18 May 2006, Tony Linde wrote:
>>> All services ought to support the getRegistryEntry (or
>> whatever it was
>>> called) method which, in the case of skynodes, should
>> return a fully
>>> complete CatalogService entry with all table and column
>> information:
>>> this is a shortcut way of getting the table/column info
>> without having
>>> to call the individual metadata methods.
>>
>> Skipping the issue of Skynode for the moment, lets consider
>> calling this query-service-metadata operation something like
>> getCapabilities instead, and having it defined by the service
>> specification. The idea would be to try to make it
>> consistent with a registry service specification, but I am
>> concerned about making a versioned service operation defined
>> by the service have too much knowledge of registry details or
>> versions.
>> In principle a service implementation does not even know that
>> the registry exists. We should try to make getCapabilities
>> compatible with what the registry reuqires but this is an
>> *interface* between the service and the registry or any other
>> client. Since it is a service operation it should be
>> controlled by the service specification, and if necessary the
>> code which loads this information into the registry can
>> perform a translation.
>>
>> In the case of a skynode or any other service, interface and
>> implementation should be separated and the service should be
>> able to describe its capabilities. In the case of a skynode
>> that would presumably include table/column info, similar to a
>> SIAP service reporting that it has optional query parameters.
>>
>> - Doug
>>
>
Received on 2006-05-26Z23:32:13