TAP information schema

[Keith Noddle]

> Good progress has been made
I'm not sure I agree. With the greatest of respect to all involved, this 
debate is more notable for those not engaged than those who are. If we 
continue along this track and time line, we risk ignoring the hard and 
detailed work that went into defining the VOResource family of schemata. 
We also ignore the investment various VO projects have made in them. 
Furthermore, without a context (i.e. Use Cases) within which to frame 
the current Info Schema work, how can we be sure it is either complete 
or optimal?

It seems logical to me that we elect to use the existing body of 
approved work to define what content metadata are returned from a TAP 
V1.0 (note: V1.0) compliant service and move onto the main body of work 
for TAP V1.0, namely the definition of how we process and manage ADQL 
queries. The sorts of questions we should be addressing are:

- SOAP or REST?
- Synchronous?
- Asynchronous?
- If asynch:
   - how do we handle return of results?
   - VOSpace?
   - Staging?
   - What are the issues for either?
- etc

If we focus on these and strive to keep TAP V1.0 as simple as possible, 
we can get it approved and move onto examining the more challenging (and 
interesting) problems that lie ahead, especially the definition of the 
Use Cases we are trying to address with Table Access in general.

Keith.

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH         Web:    http://www.astrogrid.org