[TAP] 0.5 draft

[Tom McGlynn]

Hi Pat,

Since I'll be missing the TAP meeting tomorrow, I thought I'd just 
reiterate a couple of points that I mentioned to you for more general 
discussion.

I've looked over the draft and scribbled lots of comments but these are 
primarily issues for clarification or relatively minor points.  There 
are two significant issues that do worry me though:

First, I think it is inappropriate for it to be a requirement that a TAP 
service be registered for it to be a TAP service (2.1).  This seems like 
an unnecessary entangling of protocols.  An appendix which discusses how 
a TAP service may (or even should) be registered would be perfectly 
appropriate.  I can see lots of uses for TAP services that might not be 
registered and making it a requirement to register significantly 
increases the burden on data providers.

Second, the metadata story is very confusing.  There are -- I think -- 
four distinct ways to get metadata at the table level.  I don't know if 
all of these are needed or whether there is some redundancy that can be 
eliminated.  Regardless there needs to be a much clearer explication of 
what metadata can be gotten in each method.  This may lead to a 
discussion of what's appropriate for a final standard, but we (or at 
least I) need more clarity as to what the current document is requiring. 
  Even if we decide to keep all of the current requirements, a clearer 
exposition will make it easier to implement.

Regards,
	Tom

Patrick Dowler wrote:
> 
> I have posted TAP 0.5 to the wiki. This is the last draft before the 
> meeting in Strasbourg.
> 
> 
> http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/TableAccess
> 
> 
> Included here are many small fixes and clarifications (thanks to 
> Francois, Mark, Bob, and others) and some more material changes derived 
> from recent mailing list discussions:
> 
> 
> + added TAP_SCHEMA.keys following the addition of ForeignKey to 
> VODataService
> + clarified CVS format to be compliant and refer to relevant RFC
> + added optional TSV output format
> + allowed more flexibility in setting HTTP response codes when an error 
> occurs
> + consistently use application/x-votable+xml mimetype
> 
> 
> TODO:
> 
> 
>  From what I can see, the issue of mapping between VOTable and ADQL 
> column/datatypes remains the biggest outstanding issue. The table in 
> section 2.5 has been made less specific (VOTable: format -> VOTable: ? ) 
> pending discussion and resolution.
> 
> 
> The section on child resources for async queries is out of date and 
> needs to be tweaked w.r.t. the latest UWS spec. In addition, we need to 
> specify the XML output describing the UWS "job": this is mostly 
> specified in UWS (inc. schema) but we need to specify how to include 
> TAP-specific params/values.
> 
> 
> 
> 
> -- 
> 
> 
> Patrick Dowler
> Tel/Tél: (250) 363-0044
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2M7
> 
> 
> Centre canadien de donnees astronomiques
> Conseil national de recherches Canada
> 5071, chemin West Saanich
> Victoria (C.-B.) V9E 2M7