I like the idea of a flexible run-time grammar, but it sounds too good to be true in a general purpose kinda way.
My idea isn't perfect for humans, but at least lets you use queries not hard coded.
But in my idealistic view, getting something (near) perfect for humans is what a QueryParser is all about. And, of course, this is domain and application specific in a lot of ways.
[5] the point
Be backward compatible and "natural" for existing query syntax, but leave a hook so that if you innovate and define new query expansion code there's some hope of someone using it as they can in theory drop it in and use it w/o coding. Right now if you create some code in this area I suspect there's little chance people will try it out as there's too much friction to try it out.
I'm still grasping for a happy medium between the current QueryParser and this idea of an awkward syntax general purpose pluggable parser.
Interestingly the current QueryParser is pluggable in some interesting ways thanks to the getters for each query time being overridable. For example, disallowing wildcard and fuzzy queries, enhancing range query to handle different formats, and changing PhraseQuery into a SpanNearQuery are all tricks I'm including in Lucene in Action.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
