Mike Taylor wrote:

>>Date: Wed, 3 Nov 2004 11:01:14 -0600
>>From: "Thomas G. Habing" <[log in to unmask]>
>>
>>As part of developing a CQL parser [...]
>
>
> Hi, Thomas, it's good to hear from you.  I _was_ going to ask why
> you're writing your own CQL parser when there are already free ones in
> four different languages; but then I realised you're probably writing
> in Visual Basic -- right?

Yep.  Eventually, I plan to release the parser as an ActiveX DLL,
similar to the VB ZOOM.  Right now its just a collection of VBScript
functions.

>
>
>>I have been collecting sample queries.  My sample test page is:
>>
>>   http://gita.grainger.uiuc.edu/registry/sru/test.htm
>>
>>You can click on a sample query to generate the XCQL equivalent.
>
>
> What a useful page!
>
>
>>However, there seem to be a few examples floating around, such as:
>>
>>   title = ((dinosaur and bird) or dinobird)
>>
>>that do not seem to be supported by the BNF, either the 1.0 or 1.1
>>versions.  My questions is are these valid queries, or am I miss
>>reading the BNF?
>
>
> <ahem>
>
> You are not misreading the BNF; on the contrary, the BNF is
> miswritten.  You are correct that, as currently written, the offical
> CQL grammar arbitrarily prohibits such perfectly reasonable and useful
> queries as:
>         author=(kernighan or ritchie)

Hmmm...  Thus far my parser uses regular expressions pretty much derived
from the BNF.  Looks like if I want to keep up with all the other
parsers on the block I will need to deviate a bit to support this.    :-)

Thanks for the info.

Tom

>
> There is no good reason for this prohibition (indeed, I am
> hard-pressed even to think of a _bad_ reason for it), so three of the
> four well-known parsers (my Java one, Adam's C one and Ed Summers's
> Perl one) all go right ahead and parse this in the obvious way,
> generating the obvious XCQL which cannot possibly be interpreted as
> meaning anything other than what it obviously means.  And, as you
> noticed, my tutorial also goes right ahead and tells people to use
> this useful construction.
>
> The correct outcome here is for the CQL grammar to be fixed.  I don't
> see that happening before v1.2, which is not slated for any time soon,
> but when 1.2 comes around I will dedicate 23 hours a day to making
> sure this piece of brain damage is excised from the specifications.
>
> In the mean time, a choice confronts you in the development of your
> parser: either you can stick to the letter of the what the official
> grammar says, and make a less useful piece of software; or you can
> make something that your users will not keep emailing you with
> complaints about.
>
> Tricky call, huh?  :-)
>
>  _/|_    _______________________________________________________________
> /o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
> )_v__/\  "I'm not a lawyer; I have, however, done some dumb things"
>          -- Jane MacDonald.
>
> --
> Listen to free demos of soundtrack music for film, TV and radio
>         http://www.pipedreaming.org.uk/soundtrack/