Bridging the VOSI-TAP gap (Pt. 1)
Ray Plante
rplante at poplar.ncsa.uiuc.edu
Wed Oct 28 08:59:58 PDT 2009
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:
http://www.ivoa.net/xml/VOSIAvailability/v1.0
http://www.ivoa.net/xml/VOSICapabilities/v1.0
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 standard
>> VOResource extensions.
>> Note:
>> In order for the service to be recognized as compliant with a
>> particular standard protocol (such as Simple Image Access, Simple Cone
>> 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
>> protocol.
> -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:
Note:
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 Capability
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).
>> 6) Appendix 1: Replace Availabiltiy schema listing with new VOSI schema
>> listing.
>
> -1, see argument above.
Okay, as noted above.
Other comments?
cheers,
Ray
More information about the grid
mailing list