lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mark harwood <>
Subject Re: "Advanced" query language
Date Thu, 22 Dec 2005 15:42:28 GMT
Sorry, slip of keyboard meant I posted last message

Hi Chris,
Thanks for taking the time to review this.
> 1) I aplaud the plugable nature of your solution.

I think that's definitely a worthwhile objective.

> 2) Digging into what was involved in writting an
> ObjectBuilder, I found...
> don't really feel like
> the API has a very clean seperation from SAX.

True. The efforts to remove state management were
entirely around the hand-off between one ObjectBuilder
and any "child" Object Builders - ie thinking of the
processing chain like the cartoon where one big fish
is about to eat a smaller fish, which is about to
eat a smaller fish which.... etc. The parser handles
stack of individual ObjectBuilders and their
consumption thus relieving one level of SAX-based
state management that a "just one big fish" approach
to parsing would take. 
However within each individual ObjectBuilder they have
responsibility for handling SAX apis to configure
themselves. My assumption was SAX would be a
familiar/useful API but I guess that may be wrong.

> I think that the ideal API wouldn't require people
> writing ObjectBuilders
> to know anything about sax, or to ever need to
> import anything from
> org.xml.** or javax.xml.**
Fair enough. I presume we want to maintain the
position that Lucene should not have any dependencies
other than JDK1.4?
I did look at Commons Digester but that seemed to want
to suck in logging, beanutils etc so embarked on my
own lightweight SAX-based implementation.

> 3) While the *need* to maintaing/pass state
> information should be avoided.
> I can definitely think of uses for this framework
> that may *want* to pass
> state information -- both down to the ObjectBuilders
> that get used in
> inner nodes, as well as up to wrapping nodes, and
> there doesn't seem to be
> an easy way to that. 
State "passed down" is something I saw as a potential
addition to the "Parser" object shared by all
ObjectBuilders eg a Map that was associated with
stack level.

> The best example i can give is if someone (ie: me)
> wanted to use this
> framework to allow boolean queries to be written
> like this...
>    <BooleanQuery>
>       <TermQuery occurs="mustNot" field="contents"
> value="mustNot"/>
>       <UserInput occurs="must">"a phrase"
> fuzzy~</UserInput>
>    </BooleanQuery

I did consider that my earlier version of BooleanQuery
be simplified to:
  <MustNot><TermQuery field="contents" value="foo"/>
  <Must><UserInput>"a phrase" fuzzy~</UserInput>

Although the "occurs" info could be set in the child
object as in your example that pushes some parsing
responsibility down into child elements and I feel
slightly uncomfortable about that as a technique. It
introduces the potential for nameclashes when mixing
various object builders and complicates documentation.
Its the same uncomfortable feeling I get from multiple

> Going the ooposite direction, I'd like to be able
> to have tags that set state which is accesible to
descendent >tags

Seems entirely reasonable. - See earlier comments
about Parser Stack.

I'll spend some time studying your psuedo code in more
detail later.



Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message