>Having a query language that can express all the query capabilities
>supported
>by Lucene will allow programmers to construct a string representation of the
>query and then 'compile' it using the query parser. This way, one don't
>have to learn the internal representation of the various query classes.
That point was obvious from your first post, and I agreed its a worthwhile
goal. And, most of the features are already captured in the current query
language specification, so we're close.
But I would draw the line at anything which tries to satisfy a small
constituency by making life harder for the beginning users. Think about
the principle of "commensurate effort" -- it is unfair to ask users to
learn all about something if they only want to use its most basic
features. This should be the guiding principle behind designing a query
language. The single-quote proposal you made earlier fails this test.
So I would support extending the query language to the extent that
extensions do not interfere with people trying to do simple queries and who
don't want to have to learn about tokenizers, boolean queries, or anything
else.
--
Brian Goetz
Quiotix Corporation
[EMAIL PROTECTED] Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
_______________________________________________
Lucene-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/lucene-dev
