TAP information schema

[Alex Szalay]

My 2 cents on Sync/Async:

we desperately need this feature to build the next generation scalable
services. Not to have this is simply not an option in my opinion

I think that most of the hard work that went into VOSpace was with this
feature in mind, so I would strongly recommend that the default proposal is
to use VOSpace for async messaging

We still may want to retain the ability to do sync returns, especially for
small requests (like metadata). It would increase the responsiveness of our
services if for such requests we could expect an immediate response.

--Alex

-----Original Message-----
From: Keith Noddle [mailto:ktn at star.le.ac.uk] 
Sent: Thursday, October 11, 2007 4:55 AM
To: Doug Tody
Cc: Francois Ochsenbein; Ray Plante; Patrick Dowler; Mark Taylor; Alex
Szalay; dal at ivoa.net
Subject: Re: TAP information schema

> 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