Hi Doug!
Unfortunately I couldn't attend Beijing, so this is just a comment on your posting. And it may be entirely out of context, so apologies in advance. As always, I'm willing to be proven wrong, but I don't feel an ADQL query (or any variant of SQL) is suitable for an HTTP GET parameter. It looks a tall order to be able to escape all the possible combinations of characters that may appear, but perhaps there is a library that can already do this. I don't see any problem with using it in an HTTP PUT.
On Fri, 2007-05-18 at 01:19 -0600, Doug Tody wrote:
> To clarify, what I meant in my closing plenary comment was that
> I think what we agreed was to eliminate the use of parameters for
> query restriction (hence no POS,SIZE,BAND, no range-list constraints,
> etc.) but not the use of the basic HTTP GET parameter mechanism
> where we might have other general non-query constraint params such
> as REQUEST, VERSION, FORMAT, QUERY=<adql-string>, or whatever, which
> do not duplicate functionality found in the ADQL but which are needed
> to compose a GET/POST operation. - Doug
>
As an aside, I've been an interested spectator of the meta data debate. I'm still not sure what to make of it overall. But it does seem alarming that we could end up with a number of ways of obtaining meta data: TAP, registry, ADQL query, and presumable native SQL. I'm still reeling. However, I appreciate the point about empty VOTables: as far as I can see it would only lend itself to columnar meta data.
Regards
Jeff
-- Jeff Lusted tel: +44 (0)116 252 5358 Astrogrid Project mob: +44 (0)7973 492290 Dept Physics & Astronomy email: jl99-at-star.le.ac.uk University of Leicester web: http://www.astrogrid.orgReceived on 2007-05-18Z12:36:04