Hopefully that makes sense to someone besides just me. It's
certainly a
lot more complexity then a simple one to one mapping, but it seems
to me
like the flexability is worth spending the extra time to design/
build it.
Makes perfect sense to me, and it doesn't seem any more complex
than what's been proposed before. Actually, this may be a quite
straightforward, compact and extensible way of doing it all.
Though, I'd be careful with proposing a variety of equivalent
syntaxes as it may easily lead to more confusion than good. Let's
start with one canonical syntax. If desired, other (more pleasant)
syntaxes may then be converted to that as part of a preprocessing
step.
I should add that I'd love to see a powerful, extensible yet easy to
read XML based query syntax, and make that available to users of
XQuery fulltext search.
Here is an example fulltext XQuery that finds all books authored by
James that have something to do with 'salmon fishing manuals', sorted
by relevance
declare namespace lucene = "java:nux.xom.pool.FullTextUtil";
declare variable $query := "+salmon~ +fish* manual~";
(: any arbitrary Lucene query can go here :)
(: declare variable $query as xs:string external; :)
for $book in /books/book[author="James" and lucene:match(abstract,
$query) > 0.0]
let $score := lucene:match($book/abstract, $query)
order by $score descending
return $book
Now, instead of handing a quite limited lucene query string to
lucene:match($query), as above, I'd love to pass it an XML query
blurb that makes all of lucene's power accessible without the user
having to construct query objects himself.
Consider it an additional use case beyond what Erik and others
brought up so far...
Wolfgang.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
