On Sunday 04 December 2005 05:17, Yonik Seeley wrote:
> On 12/3/05, Paul Elschot <[EMAIL PROTECTED]> wrote:
> > Indeed, this is a disadvantage of the "function call" syntax.
> 
> It depends on the langage.  Take Python for example:
> 
> >>> def foo(a,b): print a,b
> >>> foo(1,2)
> 1 2
> >>> foo(a=1,b=2)
> 1 2
> >>> foo(b=2,a=1)
> 1 2
> >>>

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.
When the property=... syntax is optional, (as it is in python),
and when meaningfull abbreviations for the longNames above can be found,
it might actually be feasible.

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.

XML already has the property=... syntax, and there are good GUI's available
for manually creating nested XML constructs.
Also I think we can safely assume that the users that can benefit from
more complex query facilities will be able to provide queries in XML.

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

That only leaves the longNames in the examples above, but these
can be avoided by allowing short forms.

So I think using XML for an advanced query language is a good idea when:
- short forms are provided for the most common names to be used,
  much like <a href="...">...</a>, <p>  and <h3>...</h3>  in HTML, and
- it has an easy to use facility to allow different roles for
  nested constructs.

Regards,
Paul Elschot


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to