TAP information schema

[Paul Harrison]

On 2007-10 -11, at 15:15, Doug Tody wrote:

>
> Ignoring for the moment the metadata query issue, my impression from
> discussions over the past year or so is that we already have consensus
> on most of the above issues.  In short:
>
>     - The basic interface should be REST-like (consistent with the
>       other DAL interfaces unless there is good reason to diverge),
>       ideally defined in such a way that the logical protocol is
>       separate from the transport and could be layered upon other
>       distributed computing platforms in the future, such as SOAP.
>
>     - Async is required for fully-functional services; it probably
>       should be required for advanced capabilities such as multi- 
> region
>       queries, complex or large queries, etc. (in other words, require
>       async to be able to do these things).
>
>     - Sync (when it works) is *much* simpler for both the service
>       implementation and the client, and is adequate for many simple
>       queries including small queries of a single table (which can
>       normally stream) and metadata queries.  We should provide
>       for this, with an indication of overflow or other failure
>       condition; async would ultimately be required in this case,
>       service capabilities permitting of course.  Simple service
>       implementations should not be required to implement async, but
>       a "fully compliant" service (as any major data center should
>       provide) implements async.
>

The solution to this to always follow the UWS REST pattern for TAP -  
this is always asynchronous (i.e. the return of the original http  
request never contains the result) , but is actually relatively  
simple - if simple is defined by being able use a standard web  
browser to issue the query and receive the result.

It is not consistent with the S*AP protocols, but I thought that  
everyone is agreed that TAP is not "simple" in that we have cone  
search for that. TAP, I thought, was supposed to be the first "second  
generation" service that benefits from all of efforts that the Grid  
WG have put into designing a simple asynchronous pattern.

>     - If large amounts of data need to be managed, as well as for
>       full functionality (e.g., workflows where remote delivery of
>       results is required) VOSpace should be used.

precisely - VOSpace is the solution to the intermediate storage and  
possible local re-use of data in a TAP service - it is not the  
solution to the synchrony problem as as been suggested elsewhere on  
this list - that can be solved by UWS alone.

>
Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank