Jos: Replying to xdg, hope it's ok...

2007/1/16, Jos van den Oever <[EMAIL PROTECTED]>:

2007/1/16, Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>:
> 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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to