multiple capabilities of the same kind

[Doug Tody]

Hi Guys -

How do we handle a service which supports two versions of the same
interface - are these separate capability elements as well?  I suspect
so, in which case having multiple capabilities of the same basic type
is probably unavoidable.

Another common case might be two (eg) SIA services of different types,
e.g., one finds only whole images, the other does cutouts, but they
access the same data.

It would seem that a search should look for services of a given type,
possibly with other qualifiers such as the protocol version supported,
or specific service capabilities.  Whether these are represented as
multiple capabilities of a single resource, or separate resources,
should not matter.  In effect what we search for are "capabilities"
rather than what used to be separate service resources.

In this case I don't see much point in trying to qualify the name
attribute; we should just do a search over all capability attributes.

(BTW, a SIA service registered for different bands of the same survey
data sounds like a bad idea, at least for SIAV2; distinguishing
this is what the BAND parameter is for, and one would want to use
association to associate the bands of a multiband observation in a
single SIA query).

	- Doug


On Fri, 15 Feb 2008, Ray Plante wrote:

> Hi Paul,
> 
> Thanks for bringing this up.
> 
> On Fri, 15 Feb 2008, Paul Harrison wrote:
> > We have recently come across people wanting to register services with
> > multiple capabilities of the same kind e.g. a resource with two capabiities
> > whose standardID="ivo://ivoa.net/std/SIA",
> 
> One thing that would be important to know here is what is it that the
> registrant is trying to accomplish by doing this?  What is it that is
> distinction between the two SIA capabilities.  By being part of the same
> resource, it is presumed that both access the same underlying data. Assuming
> this is true, it could be that the capabiliity metadata is different; if so,
> why?  If it is simply a matter of providing multiple base URLs for the
> endpoint of the service, then this can be provided as multiple <accessURL>
> elements withing the <interface>.
> 
> > OR
> > 
> > We amend the VOResource schema and add an extra "name" attribute onto the
> > capability element, which could be used to distinguish between multiple
> > capabilities with the same standardID by using the value of the name
> > attribute as the URI "fragment" e.g. ivo://org.mytelescope/survey#rband
> > could be used to identify the individual simple image access capability
> > within the resource.
> 
> This is an interesting and appealing idea; however, I note that VOResource has
> already passed to recommendation.  Thus, this change would have to be handled
> as a new version of the standard and passed through the process from WD.
> Given this, I would recommend that we deal with this cases with the schema we
> have.
> 
> So, let's first determine what is intended by this use case.  If there is not
> already an existing mechanism for dealing with the use case, then we should,
> for the moment as a matter of policy, recommend registering the SIAs as
> separate resources.
> 
> cheers,
> Ray
> 
>