lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mark harwood <>
Subject XML Query Parser - next steps
Date Fri, 24 Feb 2006 12:57:48 GMT
Before I commit this stuff to contrib I wanted to
sound out dev members on directions for this code.

We currently have an extensible parser with composable
"builder" modules. These builders currently only have
a role in life which involves parsing particular XML
chunks and instantiating the related Query/Filter

While useful, my question is could they/should they do
more than this?
I can see scenarios where they could be used to:

A) generate an XML representation of a given
Query/Filter object. This would solve the current
parser.parse(Query.toString())round-tripping problem.

B) provide metadata on the XML structure they deal
with. Unlike an XML schema, this metadata would be of
sufficient detail that it could be used to
automatically generate useful documentation about the
parser capabilities and, perhaps more interestingly,
be used to drive a generic query-building GUI tool.
Such a tool (Luke2?) could guide users in the
construction of queries where every single query
capability supported by the chosen parser config just
slots in as a self-defining extension with help text,
drop down choices etc.

I think these are ambitious but achievable features -
I don't feel I have the time to develop them myself
but I thought I'd throw it out here in case others
feel like it might be a worthwhile endeavour they
would want to help with.


To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

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

View raw message