lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: XML Query Parser - next steps
Date Fri, 24 Feb 2006 18:31:11 GMT
mark harwood wrote:
> 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
> objects.
> 
> 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.

This would be very useful, but couldn't it be added after this was in 
contrib?   You might reorganize things so that it fits in more cleanly. 
  For example, you might rename the builder interface to be something 
that encompasses externalization also, so that you can easily later add 
an externalize(Query) method to the interface and all of its 
implementations.

> 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.

This sounds more ambitious and of somewhat less general utility.  But 
cool nonetheless...

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message