TAP documentation issues: VOSI

[Guy Rixon]

On 29 Sep 2009, at 19:50, Tom McGlynn wrote:

> 5. I'm lost as to what I need to do to support VOSI  
> getCapabilities.  As far as I can tell there's nothing that  
> describes what the capabilities record for a TAP service should look  
> like.  Does it just reuse the existing Catalog Service?  The only  
> place I could find a reference to TAP was in discussing the table  
> metadata.  I didn't see anything in the TAP document that indicates  
> what the format of the capabilities record is to be.

The current draft of TAP 1.0 does not specify any special metadata for  
a TAP capability. Therefore, the only thing that one can write as a  
TAP capability is the basic Capability type from VOResource.  Note  
that this is nothing at all to do with the type CatalogService which  
is a sub-type of Resource, not of Capability.

To use this, I would (have) specified a single interface element, of  
xsi:type ParamHTTP, in which the access URL points to the web resource  
that is the parent of /sync and /async. E.g., if I have TAP operations  
at

   http://casx020-zone2.ast.cam.ac.uk:8080/wfs-objects/TAP/sync
   http://casx020-zone2.ast.cam.ac.uk:8080/wfs-objects/TAP/async

then my capability XML for TAP is this:

<capability standardID='ivo://ivoa.net/std/TAP'>
   <interface xsi:type='vs:ParamHTTP'>
     <accessURL use='full'>http://casx020-zone2.ast.cam.ac.uk:8080/wfs-objects/TAP 
</accessURL>
   </interface>
</capability>

A TAP client is expected to know that the given URL has child  
resources /sync and /async.
(BTW, the example above is a live, TAP implementation, albeit  
incomplete and under development. If you look at the root of the web  
application, at
   http://casx020-zone2.ast.cam.ac.uk:8080/wfs-objects/
you can get to all the VOSI stuff via your web-browser).
We have no way of saying which optional features are implemented on a  
given TAP service; DAL-WG would need to define the way of expressing  
that using one of two methods:
1. define a schema for a sub-type of Capability, as was done for SIAP  
and SSAP;
2. define separate standardID values for each option and write a  
separate capability for each, having a separate URL but no special  
metadata.

Regards,
Guy




>
> I don't see any way around this problem, so we will not be  
> implementing
> VOSI getCapabilities until we can get some further clarification.
>
>
> Doing getAvailability and getTableMetadata seems possible though TAP  
> document itself provides little support for them.  Even if we want  
> to leave the normative elements to other documents, putting examples  
> in the TAP document would -- imho -- make it much easier for the TAP  
> implementor.
>
> 6. Validators for the the syntax of the VOSI responses would be  
> nice...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090930/4262ea4b/attachment-0003.html>