multiple capabilities of the same kind

[Doug Tody]

On Fri, 15 Feb 2008, Ray Plante wrote:
> On Fri, 15 Feb 2008, Doug Tody wrote:
> > Guess I still don't understand why this is so.  These are two
> > separate capability elements, hence if the query is really looking
> > for capability elements (which are what is now a "service") it
> > should work.  Maybe the issue is that we need to query the registry
> > for capability elements rather than resources, now that we can have
> > multiple capabilities per resource?
> 
> Actually, now that the point this out, this is not a problem.  That is, not
> only do capability metatadata differ to distinguish them (as opposed to just,
> perhaps, a human-oriented text description), but you can still use the version
> attribute as the distinguishing key.

Right; we merely need to be able to query based on the capability
metadata.  Anything required for service discovery should be in the
metadata, not merely in a human readable description.


On Fri, 15 Feb 2008, Paul Harrison wrote:
> On 2008-02 -15, at 15:36, Doug Tody wrote:
> > I must be missing something.  Once you have done the search and have
> > the desired capability element (the real "service" in this scheme
> > evidently), then you just use the given serviceURL and other basic
> > service metadata and you access the referenced service.  If the archival
> > and cutout services are registered as separate capabilities, whether of
> > the same service resource or separate resources, it should work.
> 
> The point is that in the model the only distinguishing key between the
> capabilities is the standardID, so if there are two capabilities in the same
> resource with the same standardID there is nothing to distinguish the two
> capabilities apart from the human readable description - this works in an
> interactive situation where there is a human to point at the capability that
> they want, but not if you are writing a non-interactive script.

There should be no problem so long as the capability metadata contains
sufficient information, and this can be used in the discovery query.
The noninteractive script then just gets whatever metadata it needs
to access the service (in most cases just the serviceURL); this
information is extracted from the resource+capability combination
resulting from the service discovery query.

The key point is that service discovery should return
resource+capability pairings, not just a resource that may or may not
contain multiple capabilities.  This can happen either in the registry
query, or on the client side if the registry query interface doesn't
currently support this.

	- Doug