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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
