Comments on PQL

[Douglas Tody]

On Fri, 10 Jul 2009, Tom McGlynn wrote:

>   WHERE=instrument,HRI,PSPCA,PSPCB;exposure,10000/

> This is contradictory to the BNF described in the WHERE clause which 
> associates things differently.  The WHERE clause needs a syntax consistent 
> with the rest of the parameters.  The current document is suggesting a new 
> syntax with ; and , creating a hierarchy of dividers.

Ok, I think I understand your point now.  Yes, the syntax of the
WHERE clause is (intentionally) a variation on that of a normal
range list.  There is nothing wrong with this as any parameter
can define how it interprets its value string anyway it wants to.
We like to adopt an existing syntax where we can of course, but if
there is reason to diverge for a specific parameter one can do so
(a parameter with an ADQL encoded value string is another example).
The document already clearly states that WHERE departs slightly from
canonical range-list syntax.

That said, I would say the final syntax for the WHERE param is still
open for discussion.  What we have is workable and has already been
successfully prototyped, and is close to the canonical range list
syntax, but certainly it is not the only way to do it.

>> 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.
>
> This is what I am suggesting.  Basically I'm adding one more level to the 
> hierarchy determining which column to use: user-specified, utype, ucd, name. 
> I also think name should be deleted from this list.

Ok, this is a reasonable and simple feature to add.

>>> 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.
>
> I don't believe there is any need for quoting, or more precisely we need 
> either quoting or an escape mechanism for characters that are special within 
> PQL but not both.

Quoting provides a single mechanism which works for both escaping
individual characters as well defeating interpretation of substrings.

> Independently there is a general question of whether text matches are case 
> sensitive or not.  Personally I like the idea that seems implicit in the 
> current examples but should be made explicit that string matches are case 
> sensitive unless they contain wildcards in which case they are case 
> insensitive.  That corresponds to standard SQL '=' and LIKE operations on 
> strings.

As the draft states (2nd paragraph from the bottom on pg 14):

     While accumulating a string token, anything quoted in single
     quotes is literally included in the string, otherwise (where
     case-insensitive context applies), characters are converted
     to lower case for use in case-insensitive comparisons.
     Quoted characters are treated in a case sensitive fashion.
     Any metacharacter other than the quote character may be quoted to
     include it within a token.  A single quote may be included within
     a string by quoting it (that is, three single quotes in sequence).
     Quotes used within a string token do not delimit the token.

Hence the current proposal is that string comparisions are done in a
case-insensitive fashion by default, but one can quote strings or
substrings to force a case-sensitive comparison.

This scheme was picked as it is simple and seems to deal with all the
cases...

Your other comments basically agree with what I said earlier so I do not
repeat them here.

 	- Doug