Erik Hatcher wrote:
While there have been several different topics brought up on this thread, it seems we're diverging from the original idea. Let's consider the most basic use case example here, and I'm making it intentionally as concrete as possible:

A Swing client performs searches by communicating with a Lucene search server, which is wrapped by a RESTful servlet. The client wants to issue sophisticated queries that are not supported by QueryParser.

Breakdown: Lucene itself is not needed on the client, only an HTTP connection with bits of XML back and forth to query and send results.

Right.  A couple of additions:

1. The schema should work across Lucene implementations. It should thus avoid reliance on Java class names, Java serialization, etc.

2. We need schemas for more than just querys, but also for a full search API (num hits requested, filters, hit documents, etc.)

3. Long-term it would be good to have an XML-based API for index creation and update too. One should be able to create an index at a specified path and then add and delete documents from that index.

Focussing on a schema for queries is a good start, but I think this should fit into a larger effort. But we don't need to convene a committee to develop a Lucene XML specification. Rather someone energetic should outline things, and if most folks like it, they should implement and contribute it. It can evolve and be versioned with Lucene releases.

I think we should worry more about capturing Lucene's APIs in a non-Java specific format than about compatibility with other XML APIs and schemas (e.g., XQuery and XPath). Lucene is not an engine for searching XML. If someone wishes to implement XQuery features it should be no harder to do this against an XML API than directly against Lucene's Java API, nor much easier.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to