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. For example, can a ZeeRex record
be used as the only input to a CQL parser in order to generate valid
Note: Index names are not a problem. Its the relation and modifiers
that I am not certain of.
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. 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 (???).
So the query
dc.title <>/stem monies
when using the Bib-1 attribute set would be an error (???).
Note that using the new Attribute Architecture the rules are different.
So the CQL parser needs to handle both Bib-1 and the new attribute
architecture I guess (with different rules in effect).
Then I hit the pattern characters. Things like ? at the end of a string
and ^ when dealing with Bib-1 should be turned into the right truncation
attribute and 'first in field' attributes (maybe?). If the pattern becomes
comlex, then a special pattern match operator attribute would have to be
specified. But it would seem desirable for interoperability to use the
commonly used Bib-1 features where possible. Again, different for the new
Finally, exact, any, and all are interesting cases. There is no 'any'
in Bib-1 (unless I have an old printout). 'all' I guess is 'word list'.
'exact' is 'complete field'. I assume these are all relations, and so
imply the 'relation=equals' attribute type/value.
dc.title exact smith 1,4(USE=title) 2,3(relation=equals) 6,3(complete)
but what if it was exact/stem? 2,3 would be replaced with 2,101?
Or should 2,3 be omitted from the above?
This would be different for the new AA.
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?
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
I am considering never generating 2,3 (equals) and then generating an
error if the attribute lists ever have more than one value for the same
type. That is, dc.title = smith has an attribute list of 1,4 (not 1,4 2,3).
Anyone up to writing a page on sample CQL queries and the attribute lists
they should generate for Bib-1 and the new Attribute Architecture?