Nearly two months age I sent some comments on Ralph's CQL document. These
included comments on using quotes and parentheses. Below is a copy of (the
first part of) that message, because I think it is relevant for the present
discussion. I still can't find my copy of the CCL standard ....
From: Thomas Place [mailto:[log in to unmask]]
Sent: 02 April 2002 01:59
To: Z39.50 Next-Generation Initiative
Subject: RE: CQL Document
I have some minor comments.
Originally the idea was to base CQL on CCL. I liked that idea because
especially in Europe but also in other parts of the world there is some
tradition in using CCL. Anyway, the applications I am involved in are
heavily based on CCL (in combination with the CCL2RPN module of Index Data's
Yaz library). So where possible I prefer CQL to follow the CCL conventions.
What does this mean for your document? At the moment I don't have the CCL
standard available so I can't be exact on all details (which is by the way
impossible because of the inexact prose of the CCL standard - introducing
BNF's is a good idea and is something that is missing in the CCL standard).
* instead of adjacency CCL uses proximity expressed by '!'Digit or '%'Digit.
One is for adjacency and the other is for proximity where word order is not
* '=' is used for equality. I don't like the idea of having a choice between
':' and '='. If you take into account the other relationships, especially
'>=' and '<=', I think '=' is the more logical choice. Despite Theo's
arguments I think that users find '=' easier to understand than ':'. My
users don't have problems with typing in au=ralph to search for the author
* In CCL there is no need to use quotes when concatenating terms with space
as word separator. Space defaults to adjacency. I don't think that in CCL
there is difference between au=levan Ralph and au="levan Ralph", although
you could argue that in the first case the space is an implicit Boolean and
in the second case the space is just a character in a string. The last
interpretation is in line with systems that allow you to define spaces in
the context without quotes as a Boolean AND or as a Boolean OR overruling
the default definition of space as meaning adjacency; within quotes a space
is just the space character. In actual fact our application follows this
interpretation: for some databases the query /term space term/ is
interpreted as /term 'AND' term/ because these databases don't support
* Quotes can be also be used for strings that consists only of
NonBlankCharacters (whatever these are; NonBlankCharacter is in your
definitions a primitive); everything between quotes is a term.
* Parentheses are also allowed around QualifiedTerms other than
QualifiedTerm Boolean QualifiedTerm.
> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> Sent: 22 May 2002 21:47
> To: [log in to unmask]
> Subject: Re: bath, cql, etc.
> > -----Original Message-----
> > From: Ray Denenberg [mailto:[log in to unmask]]
> > Sent: Wednesday, May 22, 2002 3:41 PM
> > But in addition, though nobody mentioned it, what's the
> > implied precedence in
> > a query like "a OR b AND c"?
> I have no problems with parens around <term> <oper> <term>. I
> thought I had
> them in already.