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