Mikkel Kamstrup Erlandsen writes: > - About the query language, and just for the record, the syntax described > > on WasabiDraft is more the one from Beagle than the one from Lucene > > (which defaults to ORing, not ANDing the terms I think). This is > > probably and appropriately more intuitive for end-users. > > Which is? AND or OR? This is kind of a religious thing I guess. At wotk we > had a huge flame fest about this :-) We ended up ANDing... This was the > ruling from our usability consultants, I work at a library, and the same > usability rules might not apply to desktop search...
What I meant was that Lucene defaults to OR, Beagle to AND and that the latter seems more intuitive to me but I don't really care either way. This is just for clarification. There are mentions of the Wasabi language being a Lucene subset on the draft page, this is wrong. No big deal, just to avoid inconsistencies. > > [about switch requirement list] > > Yeah, I admit that the current requirements was a bit arbitrary, I just > needed to put something there... > The idea with author and title and such was to take dublin core into > consideration (which should probably not be mandatory for indexers). > > The group switch is another deal. As I've pointed out before I think this is > a really really useful switch to application developers, and as it has been > pointed out elsewhere in this thread it is not always and easy task to group > files. I have no problem with the list, just with the "mandatory" mentions. I think that a back-end engine may still be useful if it doesn't provide an "author" field, it may have other qualities :) The "group" idea is a very good one I think, but we can imagine a user with a preferred engine specialized for office files, who always searches office files and couldn't care less about "group". Should we forbid this back-end of claiming or aiming for wasabi compatibility because it doesn't do groups ? Maybe there should be a "recommended" mention between mandatory and optional. > > [sample parser] > > There are several ways to do this. One idea could be to provide stand alone > libs for QT and GObject... Ie. no "bindings" just pure implementations. I agree. I think we should also have a toy/"throw away" implementation quite fast, this will help with detecting problems in practice. > > [Beagle use of xml as serialization format] > > Cool. Good that you took the time to look at this. Now we can dismiss that > option with confidence. Thanks. Also goes to prove that you can turn a Beagle query into XML and back if we had a doubt :) jf _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
