> Date: Tue, 9 Dec 2003 20:53:41 +1100
> From: Alan Kent <[log in to unmask]>
>
> I am squeezing in a bit of time here and there on a CQL parser. I
> was starting to generate attribute lists, but hit a few interesting
> cases.  I was trying to abstract out the attribute lists from the
> parser itself, but its a little tricky to get right.

Yes.  I'm sure you've already looked at the CQL-to-PQF configuration
files use dby both my parser (Java) and Adam's (C) -- if not, you
ought to have a look if only to save yourself the trouble of working
through the same things we did.  That's not to say that you can't do
better, of course!

> I was wondering what other people are doing (or planning on doing).
>
> A first example:
>
>     dc.title =/stem monies
>
> If using the Bib-1 attribute set, 'stem' I believe is type relation.
> But you cannot have two values for the same type, so you must not
> include 2,3 (equals) and 2,101 (stem) in the one list.

Well, that's a BIB-1 restriction, but not a Type-1 query restriction.
So whatever else you do, you want to make sure you don't enshrine the
only-one-attribute-of-each-type "rule" in your software, otherwise you
won't be able to implement the general case.

> I guess stem can be used as a modifier only if the relation is
> equals, and in that case you remove the equals relation and put stem
> in instead (???).

That sounds like The Right Thing, but Adam's parser (and almost
certainly mine too) just bungs them both in.

> So the query
>
>     dc.title <>/stem monies
>
> when using the Bib-1 attribute set would be an error (???).

Er.  I guess.  Seems pretty silly, doesn't it?  One more reason not to
perpetuate the BIB-1 dependency there, then.

> Anyway, I was wondering if anyone had implemented a CQL parser to
> the stage of binding to attribute lists, and was further wondering
> how they have resolved potentially illegal attribute combinations in
> queries for CQL queries - how 'smart' are people being?

Speaking only for myself, I am being pretty dumb :-)

> Thanks for any comments. I was trying to use a table driven
> approach, but there were these strange cases that I was curious to
> see how people resolved.

I think you should definitely go table-driven; it would be simple
enough for my parser to make a uniqueifying pass across the generated
list after the event, keeping (say) only the last generated attribute
of each type.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "Your creativity is better used in solving problems than
         in creating beautiful new impediments to understanding." --
         Henry Spencer's 8th Commandment for C Programmers.

--
Listen to my wife's new CD of kids' music, _Child's Play_, at
        http://www.pipedreaming.org.uk/childsplay/