Fw: CQL 2.0?

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

From all of the discussion of CQL last week I think there's only one point 
remaining that we need to concern ourselves with (let me know if you concur) 
and that would be the points that Tony addresses in response to the Adam's 
points.

Tony again since you won't be joining us Monday if you have a chance could 
you post a note recommending what we should do about this?

Thanks.

--Ray


----- Original Message ----- 
From: "Hammond, Tony" <t.hammond@NATURE.COM>
To: <ZNG@LISTSERV.LOC.GOV>
Sent: Friday, June 04, 2010 9:04 AM
Subject: Re: CQL 2.0?


> Hi:
>
> The changes to the CQL were, as Adam has indicated, intended to be merely
> restrictive and result from applying a more rigorous BNF. The previous BNF
> was non-standard and it used terminology that was inconsistent with the 
> rest
> of the spec.
>
> This rewrite was an attempt to fix the BNF to a published standard (here,
> ABNF) and to normalize the productions and terminology. The CQL 1.2 BNF 
> was
> quite frankly less than optimal.
>
> Of the points that Adam makes I think that #2 warrants some consideration,
> and #3 maybe less so. As for #1, do we really need the ability to search 
> for
> a boolean operator string?
>
> Cheers,
>
> Tony
>
>
>
> On 4/6/10 13:41, "Adam Dickmeiss" <adam@INDEXDATA.DK> wrote:
>
>> On 2010-06-02 16:40, Jonathan Rochkind wrote:
>>> Can anyone summarize the changes at this point (anticipated or
>>> already) between CQL 1.2 and CQL 2.0?
>> I'll give it a shot. Tony Hammond wrote a new grammar (ABNF style) so he
>> might know more. In the changes below, the names refer to the
>> identifiers as given in the new ABNF spec.
>>
>> 1. A search-term may no longer be any of the reserved names : and or not
>> prox sortby  . A search-term may only be one of the terminals :
>> quoted-string or simple-string. This means that the query
>>    title = and
>> is no longer supported. (It was in CQL 1.2).
>>
>> 2. quoted-uri-string. The new ABNF introduces a new terminal:
>> quoted-uri-string. This, however is not an allowed search-term. I'm
>> pretty sure this was not intended. Firstly it means that a lexical
>> scanners must be quite clever.. analyzing what appers to be URI or not.
>> But more importantly, it disallows queries such as
>>    link = "http://www.some.com/";
>>
>> 3. prefix-name. New terminal: prefix-name. Because it is a terminal and
>> search-term no longer allows it, it will no longer be possible to say
>>    some = a.b
>> because a.b is a prefix-name and prefix-name is not allowed for a
>> search-term.
>>
>> The solution to 2, 3 is to use fewer terminal types (simple-strings or
>> quoted-string), then and define non-terminals that have meaningful names
>> and described semantics for them (prefix-name and quoted-uri-string).
>>
>> / Adam
>>