lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: "Advanced" query language
Date Sun, 04 Dec 2005 14:26:15 GMT

On Dec 4, 2005, at 6:52 AM, Paul Elschot wrote:
> I tried rewroting the XML query in exactly this way, with a
> few property=.. constructs:
> boostingQuery(
>   matchQuery=moreLikeThis(
>                             percentTermsToMatch="0.25",
>                             docId="44",
>                             compareField("contents"),
>                             compareField("title")),
>  downGradeQuery=simpleQuery("contents")
> ....
> etc.
> But then I concluded that a GUI would be better for human input.
> Nonetheless, this syntax is simpler than XML, so it might
> be more acceptable than XML for human input.

I cannot at all fathom a use case where anything like this would be  
human enterable.  I realize, Paul, that you're after a human- 
enterable syntax that can create sophisticated queries, but XML  
certainly is not appropriate, or even a short-cut of XML (see YAML -  It's a shame there isn't (that I can find) a  
decent YAML parser in Java.

Almost all users want to enter "words separated by spaces", and very  
little else.  QueryParser succeeds fine for this purpose.

I think we should focus on the machine-to-machine use case of  
communicating a Query in this discussion.

> The problem is that query language operators form queries and have
> properties and subqueries with possibly different roles.
> The subqueries cause the need for nesting and the properties and roles
> cause the need for the property=... syntax.

> I don't know XML that well. Does it have a facility to allow  
> different roles
> for nested constructs?

I'm not following what you mean by different roles.  Could you  
provide an example.


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

View raw message