TAP 1.0: Substantive comments.

[Patrick Dowler]

Just back from holidays and had no email last week...

Thanks for the comments and editorial work Tom. We will work to improve the 
document as much as possible before TCG review.

I will answer some of these issues below as well as I can.

On Wednesday 15 July 2009 12:44:38 Tom McGlynn wrote:
> This message brings up a few issues I see in the actual TAP
> specification.  Editorial comments on the presentation in the current
> document will be addressed elsewhere.  I appreciate all the work that
> went into the standard.  Many thanks to the authors.
>
> 	Tom McGlynn
>
> 1. I'm slightly concerned about the inflexibility of the URL structure
> that is required for the sync/async and the asynchronous UWS hierarchy.
> I can imagine that services wishing to treat these differently and while
> I suppose redirects might address this is seems a little rigid.  E.g., I
> might want to have the async requests handled by an entirely different
> server.

UWS does specify a rigid resource structure underneath the /async endpoint. 
For a service like TAP, we could either (1) explicitly specify the endpoints 
or (2) specify capabilities and under that the service would tell the client 
what URL to use for the sync and async query execution. Since both sync and 
async are required, we don't really need capabilities and thus opted for #1. 
Note that VOSpace 2.0 (rest bindings) does the same thing with it's /nodes and 
/transfers resources... it is a feature of REST bindings that a small number 
of fixed resources is *typically* used as it is very simple, expecially for 
clients. 

PS-It is my understanding that capabilities are to describe supported optional 
things. If that was wrong and/or we made these resources optional, then we 
would need capabilities and then could allow URLs to vary.

> 2. The in-line table upload feature uses the element name (e.g., as
> specified in the <INPUT type=file name=xxx>)  as the name of the table
> but describes this outside the regular parameter discussion.  Thus there
> is no restriction on having table names which might conflict with
> existing parameter names, e.g., request or query.  However I think this
> would cause problems with typical libraries that interpret CGI
> parameters.  [E.g., I can't see how Perl's CGI library would handle it
> if the user had both a text element named REQUEST and a file upload
> element named REQUEST.]

The only limitation on table name is that it is a legal table name in the 
query language used. It could be that we are currently overly restrictive and 
say that it has to be a legal ADQL table name... will check and clarify if 
needed.

The UPLOAD parameter specifies a pair of values: table name and URI to the 
content (could be http url, vospace uri, etc). That usage is simple and clear. 
For the inline method, we opted for using an existing feature (the name), In 
both cases, the name and content have to be tightly coupled because a query 
can in principle upload multiple tables and join them all. 

> We should (imho) treat in-line uploads like all other parameters and
> define a parameter namespace for uploaded in-line tables.  E.g. the name
> of the parameter is 'upload:xxxx', where xxxx is the name of the table.
>   (Any kind of prefix and separator would be fine, I'm just using the
> first that comes to mind).  If this namespace (e.g., 'upload:' in my
> example) is reserved for file uploads, then the protocol can allow
> in-line uploads using the standard POST encoding -- or even for tiny
> 'files' in GET requests.  The relationship between the TAP protocol and
> HTTP is much simpler.  We have keywords and values and that's the only
> thing we need to know.  TAP is completely independent of the encoding used.

I am not too sure about this. If the parameter names are dynamic like this, 
services have to iterate through all the parameter values and parse/match 
parameter names (in addition to parsing values, which is necessary now). 

Anyway, the table name is on  the value side now, so collisions are not an 
issue as far as I can see. It doesn't seem overly http-specific to use

UPLOAD=myTable,http://example/com/mytable.xml

as it is just a value which is a pair... no more http-specific than any other 
use of key=value parameters anyway.

> 3. I'm not sure I understand what the protocol is saying in general
> about the HTTP status codes and requests.  E.g., if I do an asynchronous
> call and I get a redirect, should I expect to get a 303 next?  Is that
> legal?  This may be more editorial, but I think this area should be
> parsed out a little more.

303 is a redirect code (See Other) and UWS uses this in preference to the more 
usual 302 (Temporarily Moved?).Maybe the text is just poorly worded, but the 
intent is simply that redirects are done with a 303 instead of a 302.

> 4. Caching and getAvailability seem to bad things to have together.
> Should the protocol explicitly forbid GET based getAvailability requests?

I think GET is correct from a REST perspective. Services can (should) deal 
with caching issues following the http standard, eg:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

if their availability data is volatile (which imo it is, even though the goal 
is that it is not :-)

> 5. Returning a single result.
>
> I'm sympathetic to Francois' comments here, but opening up the
> possibility of multi-resource VOTables may substantially increase the
> complexity of TAP clients.  Would we allow resources within resources as
> well?  It's a little hard to know where to end.
...
> Some time ago there was considerable discussion of 'inventory' services
> as a standard protocol at least within the NVO, perhaps that should be
> revived more generally.

As discussed elsewhere, the single-table limitation is really an ADQL reality 
and this section will be fixed to say that result structure is dependent on the 
query language used. I agree that some more thought on aggregation services is 
needed to support collections like Vizier. 


-- 

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