Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Fri, 30 Dec 2005 17:20:22 -0800 (PST)
From: Chris Hostetter <hossman_lucene@fucit.org>
Sender: hossman@hal.rescomp.berkeley.edu
To: java-dev@lucene.apache.org
Subject: Re: "Advanced" query language
In-Reply-To: <20051223123500.60189.qmail@web26008.mail.ukl.yahoo.com>
Message-ID: <Pine.LNX.4.58.0512301655390.30476@hal.rescomp.berkeley.edu>
References: <20051223123500.60189.qmail@web26008.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org