I'm sure most of you have seen this, but there is a lot of good work
going on regarding XQuery full text searching by the W3C.  LC is pushing
a lot of the activity in this group, and using hefty document-centric
EAD examples in the testing.

http://www.w3.org/TR/xquery-full-text/

FWIW, traditionally I've been a fan of utilizing an indexing tool that
is independent from my storage.  But the indexing (a subset of Lucene)
that is embedded in the NXDB (X-Hive) and expressed in XQuery in use at
Princeton is good.  It changed my opinions a bit about having the layers
separated, and I now think that XQuery Full Text has a chance.  We only
had to switch to the full, independent Lucene to implement some features
such as weighting, etc., that the NXDB didn't include off the shelf.

Regardless, though, having a standards-based syntax for querying is a
good thing.  Or, to put it another way, at least it doesn't hurt.  Those
that don't wish to interact with an index due to standards overhead
don't necessarily have to do so.  But for some, it will fit the bill by
allowing to put in new backends and simply plugging into the standard
syntax.

Clay

Kevin S. Clarke wrote:
> On 11/27/06, Ross Singer <[log in to unmask]> wrote:
>> On 11/27/06, Kevin S. Clarke <[log in to unmask]> wrote:
>>
>> Seriously, please don't get hung up on the 'proprietary'-ness of
>> Lucene's query syntax.  It's open, it's widely used, and has been
>> ported to a handful of languages.  I mean, why would you trade off
>> something that works well /now/ and will most likely only get better
>> for something that you admit sort of sucks?
>
> It's not that fulltext for XQuery sucks... it just doesn't exist
> (right now people do it through extensions to the language).  I would
> expect that the spec that gets written will not be that far from
> Lucene's syntax.  You are talking about the syntax that goes into the
> search box right?  I don't expect an XQuery fulltext spec will change
> that -- it is just how you pass that along to Lucene that will be
> different (e.g., do you do it in Java, in Ruby, in XML via Solr, do
> you do it in XQuery, etc.)
>
>> And I agree with Erik's assessment that it's better to keep your
>> repository and index separated for exactly the sort of scenario you
>> worry about.  If a super-duper new indexer comes along, you can always
>> just switch to it, then.
>
> How do you switch to it?  How do the pieces talk?  This is the point
> of standards.  If there is a standard way of addressing an index then
> you don't have to care what the newest greatest indexer is.  This
> paragraph seems in contrast to your one above.
>
> Kevin