TAP document implementation issues. Section 2.6
paul.harrison at manchester.ac.uk
Mon Oct 5 03:16:39 PDT 2009
On 2009-10 -05, at 09:39, Guy Rixon wrote:
> But the eventual TAP capability must be a sub-type of the base
> Capability, with extra, TAP-specific metadata. This is rather
> important for TAP since it has so many optional features.
OK - my mistake - I thought that a TAP capability had been defined in
the VODataService - but it looks like only the table metadata part has
been defined so far - so yes a capability needs to be defined for TAP
before it can be standardised - I guess in a separate schema now,
which is perhaps a bit of a shame....
> BTW, the base Capability is defined in VOResource (e.g. http://www.ivoa.net/xml/VOResource/VOResource-v1.0.xsd)
> , not in VODataService.
> Also, it may help to actually read the VOSI standard as well as the
> VOResource schema. :)
> On 5 Oct 2009, at 09:28, Paul Harrison wrote:
>> On 2009-10 -01, at 21:39, Douglas Tody 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
>>> This is correct. The TAP specification does not yet define the
>>> Capabilities metadata. This is a major omission but will have to
>>> wait for the next version. More prototyping is needed to understand
>>> better what is optional (e.g. advanced ADQL functionality), before
>>> we can fully define a standard Capabilities matrix for TAP.
>> what is required for TAP getcapabilities metadata is fully
>> described in http://www.ivoa.net/Documents/VODataService/ - VOSI
>> Capabilities are identical to the Capabilities elements of registry
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dal