an analogy

[Mike Fitzpatrick]

On Fri, Feb 13, 2009 at 12:48 PM, Robert Hanisch <hanisch at stsci.edu> wrote:

>
>  There seems to be a real band-wagon effect going on here, toward this idea
> of separating ParamQuery from the main body of the TAP specification.  On
> the surface I see why people might see this as elegant or clean.  In
> practice I think it is unnecessary and actually makes a bigger mountain
> from
> a mole hill.



    Having just reread the spec, ADQL queries are essentially passed thru to

the backend via the QUERY string, the same would be true for XQuery or
SQL with the appropriate LANG setting.    If we take Pat's suggestion a bit
further, i.e. treat  PQ as a separate language, then the service interface
would
collapse the REQUEST parameter to use a single value (REQUEST=query)
for queries, and the following queries would be equivalent representations
using AQ and PQ:

  http://url/TAP/sync?REQUEST=query&\<http://url/TAP/sync?REQUEST=query&%5C>
     QUERY="select * from magtab as m where m.r > 10 and m.r < 16"

  http://url/TAP/sync?REQUEST=query&LANG=param&\<http://url/TAP/sync?REQUEST=query&LANG=param&%5C>
    QUERY="FROM=magtab;WHERE=r,10/16"

That is. assuming we had the debates to define the PQ 'language' and believe

that that role of QUERY/LANG is to deliver some opaque query language to
the  service.  Is the above actually what's being considered  or would PQ as
a language be used to determine the service parameters?

Where this breaks down is the idea that PQ is somehow applicable in other
DAL services and thus deserving of independent development.  Clearly the
above query is meaningless in SIAP/SSAP although it may be valid PQ, so
the PQ definition would have to include a table saying which services
support
which parameters. But isn't that part of the service definition we already
have?
I agree we should  have consistent definitions of e.g. the range syntax used

and the meaning of POS, the DAL2 architecture document seems more
appropriate than declaring these to be part of a new language.

OTOH, what we have now is a query of the form

http://url/TAP/sync?REQUEST=ParamQuery&<http://url/TAP/sync?REQUEST=query&LANG=param&%5C>
FROM=magtab&WHERE=r,10/16

As a service provider, it is clear ParamQuery is optional, but I would be
less
likely to implement it as a separate language option than if it were just an

optional set of parameters in the service definition.  As a client
developer,
I also fail to see any great advantages in what's being proposed.

Reading the current draft as a TAP newbie, it looks perfectly reasonable (if
in need of a little work still).  I agree with Doug that the PQ elements are
part
of the service specification and don't constitute a language in itself, and
I also
agree with Ray in calling for more specific discussions about what is
objectionable in the current doc.  Otherwise, I'm going to hide out with
Arnold
until all the free beer starts flowing in Strasbourg.....

Cheers,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090213/dad44b58/attachment-0003.html>