Sorry, I think the problem may be I've put the parenthesis in the wrong
place. I said:
CqlString ::= Term | Term Boolean CqlString
Term ::= QualifiedTerm | "(" QualifiedTerm ")"
and instead should have said:
CqlString ::= Term | Term Boolean CqlString | "("Term Boolean
So the bnf would instead be:
CqlString ::= Term | Term Boolean CqlString | "("Term Boolean CqlString")"
Term ::= [IndexQualifier Relationship] SearchTerm
IndexQualifier ::= [IndexSet.] IndexId
IndexSet ::= SimpleString
Relationship ::= "=" | "<" | ">" (etc)
IndexId ::= SimpleString
Boolean::= 'AND', 'OR' (etc)
Does that help? Putting parenthesis around "term operator term" should
resolve the ambiguity question (though perhaps not the way you would
prefer). Whether we still need parenthesis (or something) around term is
still a question.
----- Original Message -----
From: "Alan Kent" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, May 23, 2002 8:09 PM
Subject: Re: bnf for cql
> On Thu, May 23, 2002 at 07:41:12PM -0400, Ray denenberg wrote:
> > > CqlString ::= OrTerm *( "OR" OrTerm )
> > > OrTerm ::= AndTerm *( "AND" AndTerm )
> > > AndTerm ::= Term *( "NOT" Term )
> > > Term ::= QualifiedTerm | "(" CqlString ")"
> > This raises (again) the question, are we defining a wire- or
> > human-readable/typeable-syntax, and of course, the answer is something
> > between.
> Hmmm. Not quite human, not quite computer format. I know!
> How about programmer friendly!!! :-) :-) :-)
> More seriously, I was not sure how your comment related to the grammar.
> In both cases, boolean operator priority is important to specify.
> Writing it into the grammar I thought was a generally accepted way
> to make it explicit and avoid ambiguity (the old grammar did not
> address operator priority, and so was either ambiguous, or had
> left-to-right semantics always (which is uncommon).
> I actually think being programmer intuitive is important for SRW/SRU.
> Being end-human friendly is benefical. But to express complex concepts
> in a query, you are going to have to be trained. So being logical
> and consistent is a good goal.
> > But with this definition, will the productions be intuitive enough?
> I am not sure - are you mixing how the grammar is written with semantics
> of what the grammar expresses? The above sort of grammar of having
> rules per operator is the standard approach for specifying operator
> priorities unambiguously in grammars. Its what any programmer who
> had to implement CQL would be looking for (well, in my opinion anyway -
> I majored in compiler writing back in my Uni days).
> > > * I will raise (not propose) that CCL allows multiple IndexQualifiers
> > > in front of a single term (so you can say Author,Title="smith").
> > Is this just to avoid constructing an OR? or does this refer to an
> > Author/title index?(In which case, just define an Author/title index.)
> It was an OR, which is why I raised it but not proposing it. It was a
> CCL shorthand. CQL is formally complete without it.