[Wasabi Proposal] XML desktop query language
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Tue Jan 16 21:55:19 PST 2007
Jos: Replying to xdg, hope it's ok...
2007/1/16, Jos van den Oever <jvdoever at gmail.com>:
> 2007/1/16, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > I updated the schema quite a bit to reflect your feedback :
> > http://grillbar.org/wasabi/drafts/wasabi-query.xsd
> > Changes:
> > - Split out selectors in two groups. extendedSelectionTypes and
> > selectionTypes. Selectors in the last group are mandatory, but the
> > are optional.
> > - Add lessThanEquals, greaterThanEquals, and startsWith selectors to
> > selectors.
> > - Add regExp extended selector. Rename distance to proximity selector.
> > - Move a whole bunch of attributes to the string type. See the
> > stringAttributes and extendedStringAttributes.
> > I'm in a hurry right now, so I'll have to elaborate later. Cheers,
> > Mikkel
> > PS: I still want to tweak the proximity selector a bit, by moving the
> > distance specifier to an attribute
> > PPS: There is now more documentation inside the schema it self, so I
> hope it
> > makes more sense now.
> Hi Mikkel,
> Ah another spec. I've not even had time to start implementing the
> first. ...
Don't implement any specs yet! If we're following the roadmap (
http://wiki.freedesktop.org/wiki/WasabiRoadMap) we should have an official
proposal ready by 24/1. This will be a proposal until it has had a month of
evalution by various interested parties before we finalize it.
There has not been any responses to the roadmap, so I have to assume
everyone is ok with it... If you decide to follow up on it please do so in
the Roadmap thread.
- I like the tendency towards using uris for fieldnames. This fits
> nicely with the RDF ideas currently in fashion in Tracker and Nepomuk.
Unfortunately we have to wait until after the api+language spec to settle on
those - then we'll be nearing the topic of your original thread! :-D (see
- Can you somehow add a way to let the user know which feature of the
> spec are implemented? You could name the different features and let
> the search engines have an introspection method that gives back the
> list of implemented features.
Yes. As the language spec stands now there is a core set of features you
must support and then an optional extended set of features that cannot be
expected from all indexers. I also think we should have some introspection
method for these extended features.
There are both extended attributes and elements, but with a naming
convention a method like (in both simple and live apis):
getExtendedFeatures(out as feature_names)
could do. A return value of ["fuzzy", "regExp"] would translate to "I
support the fuzzy string attribute, and the regExp selector".
- Stemming is a tricky business. It required language recognition and
> there are a few more snakes in the grass. I'd prefer to have stemming,
> if included, be optional and certainly not the default.
It is in the extendedStringAttributes now. Following my previous example you
would add "enableStemming" to your getExtendedFeatures response if you
- Will there be test suits so that we can test how well the spec is
I hope so. They are not mentioned in the roadmap however, I would really
really like a wasabi-compliance test suite.
To Jean-Francois and Fabrice: how about a shared LGPL C++ lib for
> getting a C++ object from the xml?
Allow me to answer anyway :-) : Yes please! In the roadmap is also mentioned
toolkit bindings. So the Qt-inclined of you may also want to colloborate on
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg