Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2003)Back to main ZNG pageJoin or leave ZNGReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Thu, 11 Dec 2003 10:20:53 GMT
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Mike Taylor <[log in to unmask]>
Subject:      Re: Attribute lists for queries - what are people doing?
Comments: To: [log in to unmask]
In-Reply-To:  <[log in to unmask]> (message from Alan
              Kent on Tue, 9 Dec 2003 20:53:41 +1100)

> 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/


Back to: Top of message | Previous page | Main ZNG page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager