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