After our recent discussions on this topic I've found some time to put
together a first cut of a SAX based Query parser, see here:
http://www.inperspective.com/lucene/LXQueryV0_1.zip
I've implemented just a few queries (Boolean, Term, FilteredQuery,
BoostingQuery ...) but other queries are fai
Mark,
This is very cool. When I was at TripleHop we did something very similar where
both query and results conformed to an XML Schema and we used XML over HTTP as
our main vehicle to do remote/federated searches with quick rendering with
stylesheets.
That however is the first piece of the puz
On 12/15/05, markharw00d <[EMAIL PROTECTED]> wrote:
> At this stage I am more interested in feedback on parser design/approach
Excellent idea.
While SAX is fast, I've found callback interfaces more difficult to
deal with while generating nested object graphs... it normally
requires one to maintain
STAX would probably make coding easier, but unfortunately complicates
the packaging side: one must ship at least two additional external
jars (stax interfaces and impl) for it to become usable. Plus, STAX
is quite underspecified (I wrote a STAX parser + serializer impl
lately), so there's r
I think implementing an XQuery Full-Text engine is far beyond the
scope of Lucene.
Implementing a building block for the fulltext aspect of it would be
more manageable. Unfortunately The W3C fulltext drafts
indiscriminately mix and mingle two completely different languages
into a single l
Agreed, that is a significant downside.
StAX is included in Java 6, but that doesn't help too much given the
Java 1.4 req.
-Yonik
On 12/15/05, Wolfgang Hoschek <[EMAIL PROTECTED]> wrote:
> STAX would probably make coding easier, but unfortunately complicates
> the packaging side: one must ship at
Right now the Sun STAX impl is decidedly buggy compared to xerces SAX
(and it's not faster either). The most complete, reliable and
efficient STAX impl seems to be woodstox.
Wolfgang.
On Dec 15, 2005, at 7:22 PM, Yonik Seeley wrote:
Agreed, that is a significant downside.
StAX is included
> While SAX is fast, I've found callback interfaces
> more difficult to
> deal with while generating nested object graphs...
> it normally
> requires one to maintain state in stack(s).
I've gone to some trouble to avoid the effects of this
on the programming model.
Stack management is handled by t
