Re: [sdx-developers] GPL vs ASF

[Pierrick Brihaye]

[je reposte : l'original l'a été hier à 19h39]

Re,

Sylvain Wallez a écrit :

> > Y compris lorsque le nom de la classe, l'ordre de traitement des 
> > caractères Unicode, assez incohérent à vrai dire, sont les mêmes ?
>
> Le nom de la classe ne me parait pas particulièrement discriminant. 

Soit :-) Mais il y a tout de même la logique de l'ISO-8859-1 derrière.
D'ailleurs, un filtre digne de ce nom devrait désormais filtrer sur les
combining characters d'Unicode (on y revient) ;-)

> Quand à l'ordre des caractères, il suit globalement l'ordre croissant à 
> l'exception des codes 0153, 152 et 178, que j'avais raté en première 
> lecture. Dont acte, c'est bien un plagiat !

Voir mon commit SDX 1 :
http://savannah.nongnu.org/cgi-bin/viewcvs/sdx/sdx_v1/source/java/fr/gouv/culture/sdx/index/FrenchUnaccentedFilter.java.diff?r1=1.4&r2=1.5

Myriam a depuis fait l'escaping pour que ceux qui ne sont pas en
ISO-8859-1 puissent compiler (erreur de design fréquente).

> > Pas mal sont passées à la trappe pour des raisons parfois 
> > incompréhensibles (ou, plutôt, pour cause d'anglo-saxo-centrisme 
> > forcené :-).
>  
> Curieux. Y sont anti-français chez Lucene ?

Non. Ils veulent simplement éviter de mélanger le moteur avec des
implémentations dépendant des langues, ce qui est légitime IMHO.

Le problème, c'est qu'il appauvrissent en minuscules, ce qui n'est pas
du tout dans la tradition française et que, chez eux, Standard* =
English* :-)

> Parce qu'il y a des
> tokenizers allemands et russes depuis longtemps (2002 me dit le CVS) ?

Depuis plus longtemps que ça. Ils y étaient avant le passage chez
Apache. Noter, au passage, le traitement du russe (qui repose sur une
transcription latine) et allemand qui est... euh, discutable et qui a
pas mal surpris un sdx-user suisse.

> > Il faut bien le reconnaître cependant, un patch a désormais beaucoup 
> > plus de chances d'être intégré dans Lucene... tant qu'il ne touche pas 
> > aux analyseurs qui ont eu la chance d'être inclus dans le core.
>
> D'après ce que je vois ils sont tous dans lucene-sandbox [1].

Oui. Désormais, la lucene-sandbox rend aux auteurs ce qui appartient aux
auteurs, mais des parties plus anciennes du code les squizzent
littéralement.

> > Je contribuerai cependant bien volontiers à un Tokenizer "universel", 
> > fût-il en licence ASF :-)
>  
> Houla ! C'est techniquement faisable, ça ?

Oui. J'en ai exposé les principes il y a pas mal de temps. L'idée de
base en est de tokenizer sur des classes de caractères (Merci Unicode et
Java).

Si l'on prend cet excellent site :
http://www.fileformat.info/info/unicode/char/fee2/index.htm on a un
exposé des caractéristiques Java du caractère.

Il va soi que pour les langues alphabétiques ou syllabiques, on
tokenisera sur Character.isWhitespace() et éventuellement sur
Character.getType().

On peut également vouloir tokenizer sur Character.UnicodeBlock ou, pour
les nostalgiques des Charsets, sur CharsetEncoder.canEncode() pour ne
retenir qu'un système d'écriture particulier.

> Est-ce que ça ne dépend pas
> fortement de la langue ?

Si, bien sûr, mais rien n'empêche d'avoir des comportements prédéfinis
du style :

Tokenizer myTokenizer = UniversalTokenizer(UniversalTokenizer.LATIN);

Si un tel tokenizer était intégré à Lucene, on n'aurait plus besoin des
autres et on pourrait plancher sur... un UniversalTokenFilter :-))

A+

p.b.