Hi,
there is a new draft of the VOSI spec at http://www.ivoa.net/internal/ IVOA/IvoaGridAndWebServices/VOSupportInterfacesMandatory-0.4.pdf . This updates and simplifies the availability schema, as I'd promised to do at the last Interop.
If you are interested in monitoring availability of services, please have a look at this draft and let me know if it suits your purposes. It would be good to get this accepted in/before Trieste.
If the availability schema is acceptable, then (AFAIK) the only thing to add to the spec is the way of registering VOSI endpoints. In AstroGrid, we put a capability for the capabilities endpoint and a separate one for the availability, like this:
<capability standardID="ivo://org.astrogrid/std/VOSI/ v0.3#capabilities">
<interface xsi:type="vs:ParamHTTP">
<accessURL use="full">http://casx019-zone2.ast.cam.ac.uk/
community/VOSI/capabilities</accessURL>
<queryType>GET</queryType>
<resultType>application/xml</resultType>
</interface>
<capability standardID="ivo://org.astrogrid/std/VOSI/ v0.3#availability">
<interface xsi:type="vs:ParamHTTP">
<accessURL use="full">http://casx019-zone2.ast.cam.ac.uk/
community/VOSI/availability</accessURL>
<queryType>GET</queryType>
<resultType>application/xml</resultType>
</interface>
As you can see, this uses the basic capability from VOResource - i.e. no special schema for VOSI - and a pair of standardID values. For the VOSI spec, we just need to choose official standardIDs to replace the AstroGrid-prototype values. Does anybody see any problems with these:
ivo://ivoa.net/std/VOSI#capabilities
ivo://ivoa.net/std/VOSI#availability
If there is problem with using the fragment identifier to distinguish the two kinds of capability in one VOStandard document, then the simplest alternative would be
ivo://ivoa.net/std/VOSI/capabilities
ivo://ivoa.net/std/VOSI/availability
implying two VOStandard documents. (Can anybody from Registry-WG comment on this? Paul? Ray?)
AstroGrid has been using the arrangement above for a while now. It works pretty well and allows our registration UI to be concentrated in the registry service, which was the requirement stated in Beijing.
I realize that this is all pretty boring...but if those with an interest can agree to the ideas above then we can finish it in Trieste and you won't be bothered with it again :)
Cheers,
Guy
 Received on 2008-05-08Z11:55:25