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]
