Re: [sdx-developers] GPL vs ASF

[Pierrick Brihaye]

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.