XML Query Parser - next steps

[mark harwood <ma...@yahoo.co.uk>]

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

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.


Cheers
Mark





		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

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

Re: XML Query Parser - next steps

[Chris Hostetter <ho...@fucit.org>]

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

I would argue that the existing interface names are fine -- but the
concrete class names should probably be changed to not explicilty mention
"Builder".  Down the road, "Formater" interfaces can be defined, ie...

  public interface QueryFormater {
    public Element formatQuery(Query q);
  }
  public interface FilterFormater {
    public Element formatFilter(Filter q);
  }

...and if it makes sense for the existing classes to start implimenting
them they can, but clients that want to write their own Queries (and their
own Builders for those Queries) don't have to worry about implimenting a
format method unless they care about it that functionality.



-Hoss


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

Re: XML Query Parser - next steps

[Doug Cutting <cu...@apache.org>]

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