 |
 |
[sorry, if this message is sent twice] 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 .... Thomas -----Original Message----- From: Thomas Place [mailto:[log in to unmask]] Sent: 02 April 2002 01:59 To: Z39.50 Next-Generation Initiative Subject: RE: CQL Document Ralph, 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 important. * '=' 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 ralph. * 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 adjacency. * 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 > LeVan,Ralph > 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. > > Ralph > >