[nvo-techwg] Comments on PQL

[Doug Tody]

Hi Tom -

Thanks for the careful look at this.  I'll look at your detailed
comments more carefully later but can comment on some of your key
issues now.

 	- Doug


On Thu, 9 Jul 2009, Thomas McGlynn wrote:
> We should not let the WHERE parameter drive the definition of
> parameters generally.

It is the other way around actually.  WHERE just adopts the standard
range-list syntax used elsewhwere in DAL.  We don't have to do this
if we decide we need something more complex for WHERE, but the
current syntax addresses the most common queries simply.

> - The multicone discussion is unclear.  The coordinate systems
> supported are not discussed (nor in the standard POS for that matter)
> and how the positional columns are found is confusing.

I agree some mention of supported coordinate systems should be added.
This is complicated however by the need to support solar and planetary
data with the second-generation interfaces.  In general we specify
ICRS support as the default, encourage galactic, and say that anything
else is possible and would be indicated in the service capabilities.

> Users should be able to explicitly specify the columns in the uploaded
> tables where the positions are to be found.

Yes, but this can be done on the client side when the input multipos
table is generated.  Other issues such as conversion of CSV or whatever
to VOTable can be addressed that way as well.  In general if we are
uploading tables some preparation of the input table is going to be
required in any case.  Use of metadata to identify the input columns
(default columns anyway) is attractive as this allows the operation
to be automated.  Once we have such a table it can be used many times
without having to explicitly specify the columns.

An alternative would be to use a parameter or set of parameters to
allow the columns to be explicitly identified.  Metadata, if provided,
could still be used to automatically identify the default columns.

> - I believe there is a running confusion in the document regarding
> the need for escaping characters.  While many characters in PQL defined
> strings will need to be escaped when PQL parameters are encoded
> in an HTTP request, that is not part of PQL and need not be discussed
> here.

This is a valid point so long as we have a strong separation of the
logical service interface from the transport (HTTP in this case).
In general in TAP and PQL we have only partially done this so far.

> The only character that might need to be escaped within
> PQL itself is ',' (and possibly '/' if we allow range searches
> in strings).  I'd prefer a backslash quoting for these if we decide
> we need it since otherwise there are multiple levels of URL encoding
> required in sending and receiving messages.

The issues of URL encoding and escaping (quoting) characters within
a WHERE clause are distinct.  An escape mechanism is needed to
include metachacters within strings.  Quoting is needed as well,
e.g., to force case sensitive treatment of strings or substrings.
The simplest thing is to use the same quoting mechanism for both cases,
which is what the document currently proposes.

> - I strongly disagree with the behavior suggested in section 2.8.

(This refers to ignoring data model-based query constraints that don't
apply to the data being queried).  I agree that this probably does
not need to be in this document, and is probably hard to understand
without more context.  But what it describes is how DAL queries such
as SIA and SSA have worked for years.  For example if we query for
images by POS and BAND but no information on the spectral band is
available, the query ignores the BAND constraint without error,
leaving it to the client to refine the query.  General discovery
queries are not the same as table data queries and tend to err on
the side of including candidate datasets.  If we did not do this we
could not pose the same query to 100 services.  But it is not how
one would normally want to query a simple data table.

Basically this is a good example of specific parameter semantics that
cannot easily be generalized and are better left to the specification
of an individual interface.  It is a carry over from an attempt to
generalize PQL and should probably be removed in the next draft.

> - The parameter qualifier syntax seems to have no real purpose and doesn't
> seem to be needed. An additional parameter could be used to specify
> the coordinate system.  I'd find this much cleaner.
> [I saw no other uses of qualifiers.]

This is how POS,SIZE, BAND, etc. work in SSA; one can specify a
qualifer in some of these cases.  Again, this is PQL attempting to
generalize specific syntax and semantics of existing DAL interfaces.
I agree that this is confusing if one does not understand where it is
coming from and we should clean some of this up in the next draft.
In general this level of detail is best left to the individual
service interfaces.

 	- Doug