TAP document implementation issues. Section 2.6

[Paul Harrison]

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. :)
>
> Cheers,
> Guy
>
>
> 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  
>> entries.
>>
>> Paul
>


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