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 -
http://www.yaml.org/). 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.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
