[Wasabi Proposal] XML desktop query language

[Mikkel Kamstrup Erlandsen]

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
> extended
> > are optional.
> >  - Add lessThanEquals, greaterThanEquals, and startsWith selectors to
> base
> > 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
roadmap again)

- 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
support it.

- Will there be test suits so that we can test how well the spec is
> followed?


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
that...

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070117/e806054d/attachment.htm