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]

Reply via email to