Bridging the VOSI-TAP gap (Pt. 1)
gtr at ast.cam.ac.uk
Thu Oct 29 02:49:15 PDT 2009
On 28 Oct 2009, at 15:59, Ray Plante wrote:
> Hey Guy,
> On Wed, 28 Oct 2009, Guy Rixon wrote:
>>> 1) Section 2.1: Mandate the use of the VOSI schema for delivering
>>> capability metadata.
>> I'm not sure that all the endpoints should be covered by the same
>> schema. It's OK at the moment, but if we ever wanted to add another
>> VOSI resource (and we might for UWS-PA), then we have to change the
>> namespace for all the implementations
>> of capabilities and availability. I'd prefer to have a separate
>> schema for capabilities, somewhat like my previous email.
> This seems reasonable--I'm okay with separate schemas. If you don't
> mind though (and this is minor), I'd like to suggest that both
> schema namespaces include VOSI somewhere as a reference to the
> standard that defines them...somehthing like:
This is OK by me.
> BTW, I like your schema for capabilities better; I would be happy
> for us to adapt that one.
>>> 2) Section 2.1: Add a non-normative note explaining the use of
>>> VOResource extensions.
>>> In order for the service to be recognized as compliant with a
>>> particular standard protocol (such as Simple Image Access, Simple
>>> Search, etc.), the Capabilities metadata resource should include a
>>> capability element with an xsi:type attribute set to the
>>> standard Capability sub-type for that protocol. Standard
>>> Capability extensions, which are documented for each
>>> protocol elsewhere, provide information that is specialized for the
>> -1. It's not necessary to sub-class capability unless extra
>> metadata are needed. The standardID attribute should be enough to
>> associate with a standard protocol.
> Agreed. Changed wording:
> The value of the capability element's standardID attribute is used
> to indicate the service's support for particular standard protocols
> (such as Simple Image Access, Simple Cone Search, etc.). In the
> case of some protocols, the support for the standard is further
> characterized by additional metadata provided by a standard
> extension for that protocol. The extension metadata is enabled by
> adding a xsi:type attribute to the capability element set to the
> Capability sub-type for that protocol (see example below).
Seems good to me.
>>> 6) Appendix 1: Replace Availabiltiy schema listing with new VOSI
>> -1, see argument above.
> Okay, as noted above.
> Other comments?
More information about the grid