TAP 1.0: Substantive comments.

[Doug Tody]

On Mon, 31 Aug 2009, Tom McGlynn wrote:

> My concern here is that I don't think the document makes it clear what the 
> normal and error status codes should be for each request.  An explicit table 
> of such would be helpful.  This is particularly important when we, by policy, 
> should return something other than a normal success code for what is in fact 
> a successful request.  As a writer of a TAP server or client I'm not quite 
> sure what I'm supposed to return or look for using the current document.

I agree with this.  The issue (not resolved in earlier discussions)
is again the separation of the logical service protocol from the
HTTP transport.  Some folks want to use HTTP status codes to indicate
logical service functionality such as errors, others (including myself)
want to use HTTP status codes only within the HTTP transport.

If we more clearly separate the two then any logical service operation
successfully transacted over the HTTP protocol should return HTTP OK.
The success or otherwise of the *logical service operation* should
be separately specified by the higher level logical service protocol,
e.g., via the VOTable status packet currently used.

In this case one still has full use of the HTTP status codes for
HTTP-level functionality, such a redirect, stream compression, etc.
A client application using a client-level API would normally never
see HTTP and would be unware of things such as a HTTP redirect.
But we would still be able to fully utilize such HTTP functionality.

> My concern here is that I don't think the document makes it clear

A similar issue is the MIME type issue (MIME type of the query
response votable) which was never resolved.  Currently we allow either
"text/xml" or "application/x-votable+xml" to be returned without
specifying a default.  We want to be able to return either, but there
should be a well defined default, probably text/xml.  Otherwise if we
execute a TAP query from a browser interface it will work correctly
(render and display the returned table) for some services, but fail
(prompt for a file save) for other services.  This will set a trap
with the application behaving unreliably, forcing client apps to
specify the desired MIME type with a FORMAT parameter.

Instead we should specify MIME="text/xml" as the default behavior while
allowing use of FORMAT to force return of the application MIME type.
Hence for example a query would render in the browser by default
(as for all our current data services) but a Web query form could
have a button to optionally direct the query response to an external
application such as TOPCAT under control of the browser application
associations.

 	- Doug