: I'm personally happier to stick with one approach, : preferably with an existing, standardized interface : which lets me switch implementations. I didn't really : want to have to design a general API for parsing XML : as part of this project.
I'm not suggesting that, I'm just saying that the API people use when writting ObjectBuilders should be agnostic of the underlying implimentation -- and a good way to ensure that is to think about how it *could* be implimented using different parsing methodologies. : The parser framework was (apart from an annoying bug) : letting me construct and run this collection of : objects to create a RAMIndex , populate it, run : queries and test results. : : In this scenario the parser is used as a generic : instantiator of different objects using configurable : choice of ObjectBuilders. That's why I used : "ObjectBuilder" as the building block not just : "QueryBuilder". whoa. I hadn't even considered the possiblity of using the same parser/handler registry for doing things like index building. I thought you said you "didn't really want to have to design a general API for parsing XML as part of this project" ? :) : ie should we offer: : 1) XML Parser implementation independence (via SAX, : DOM, other interface?) I think the API should be parser independendant. but that doesn't mean there has to be multiple implimentations. : 3) Support for builders to produce *any* object : construction (not just queries/filters)? There's a differnce between producing any java.lang.Object and any Lucene related "object" (ie: query, filter, document, directory) ... I don't think it's neccessary to support any java.lang.Object, but I can get on board the idea of supporting any lucene related objects. That said, i still really, Really, REALLY like type safety, and the space of lucene objects is small enough that having seperate registries and "process" methods. As I said regarding Queries/Filters -- the caller is going to know what they are expecting, so they can call the specific method for the return object they want. : 4) Ability for Queries to write to XML (choice of : parser configs can be used to write Query/Filter : objects as well as read them?) I'm in favor of this ... but I think it's orthoginal to the issue of parsing. : 5) Ability for Parser configurations to : "self-document" the XML structures they are capable of : parsing? ie produce a schema I have no opinion on this. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
