Hi Jeff -
Both GET and POST are parameter-based so the encoding issue is only partially relevant to the issue under discussion here, which was use of data model-based parameter queries in TAP (the point of the decision was that TAP should implement only ADQL-based queries, as opposed to DM-based constructs like POS,SIZE or RA,DEC,SR).
But anyway, there actually is a standard way to include complex strings such as an ADQL expression in a GET, called URL encoding. If an ADQL expression gets large enough a POST might eventually be preferable, but for 90% of typical simple queries a GET with URL encoding would be fine, and is simpler and more RESTful for a synchronous query since the query is idempotent. Probably TAP should support both GET and POST for synchronous queries, and only POST for asynchronous queries. GET is preferred for idempotent (no side affect) references in HTTP due to the way the Web is designed, as well as for simplicity.
For information on URL-encoding see for example
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm
We already use URL encoding in VO, for example, one cannot pass an IVOA identifier containing the "#" character in a GET unless it is URL encoded.
On Fri, 18 May 2007, Jeff Lusted wrote:
> 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.org
>
>
>
Received on 2007-05-18Z14:38:23