=== Premier point ===
Je reviens sur le problème de la fonction quoteattr() du module
sax.saxutils actuellement installé sur le serveur Osmose.
Visiblement, cette fonction n'est pas du tout issue du vrai module
sax.saxutils, mais n'est qu'un stub qui se contente de placer son
paramètre entre guillemets ASCII (").
Je note que cela invalide TOUTE chaîne contenant non seulement un
caractère et commercial (&), trouvés dans les URL notamment, mais
aussi dans des noms comme "Hôtel B&B" ou "C&A", mais aussi des
guillemets ASCII, et même les caractères "<" et ">" qui ne sont pas
réencodés non plus sous la forme "&", "<" et ">" (ce que
fait la fonction originale).
La fonction actuelle remplace en revanche systématiquement les
apostrophes ASCII (') sous la forme "'" alors que ce n'est pas
nécessaire si la valeur sera retournée entre guillemets ASCII (") : la
fonction quoteattr() du module Pythin original ne le fait pas.
Bref, l'actuelle fonction quoteattr() utilisée ne fait rien d'autre
que remplacer dans la chaîne source les apostrophes ASCII (') par
"'", et encadrer la chaîne obtenue de guillemets ASCII. Elle
n'emploie pas du tout la fonction escape(), comme documentée par
Python, et ne détermine pas non plus le type de guillemets simples ou
doubles (selon lequel ou lesquels sont présents dans la chaîne source)
à utiliser pour encadrer la valeur retournée (et éviter de réencoder
l'autre type).
Ces erreurs se retrouvent par exemple (on m'a demandé de trouver un
lien dans Osmose, sur une valeur pas encore corrigée) dans :
http://rawedit.openstreetmap.fr/edit/node/739753876
(ici l'erreur signalée est sur l'ortographe du mot "Hôtel" dans "Hotel B&B")
Bref je redemande à ce que celui qui maintient le serveur
Osmose.openstreetmap.fr vérifie d'où vient la fonction quoteattr()
utilisée, car soit ce n'est pas celle importée depuis le module
sax.saxutils (elle est écrasée par une autre en conflit dans un autre
module), soit ce module pythin sax.saxutils n'est qu'un "stub" écrit
rapidement mais pas l'original sur le serveur backend.
=== Deuxième point ===
Et je continue de voir des corruptions de données issues de "rawedit",
notamment par des utilisateurs qui visiblement utilisent aussi de très
vieilles versions d'Internet Explorer sur Windows ou MacOS (plus
maintenues par Microsoft voire abandonnées complètement sur MacOS
depuis des années) parce que certaines fonctionne Javascript
fonctionnent incorrectement sur ces versions (pour correctement
encoder le texte en UTF-8 dans la fonction javascript
encodeURIcomponent). Bref c'est encore une demande pour intégrer
jQuery dans Osmose pour remplacer le code Javascript émis par le
frontend et écrit trop rapidement et mal testé pour éviter des
problèmes de compatibilité (et éventuellement les contourner si
possible, sinon afficher une erreur sur le navigateur client afin
qu'il ne puisse pas valider une valeur erronée).
D'ailleurs il me semble que les mêmes utilisateurs de vieilles
versions de navigateur, pour contourner certaines erreurs, évitent de
taper le moindre accent dans Osmose/rawedit. Mais ils ne font pas
attention du tout sur le fait que les données affichées dans Rawedit
peuvent contenir autre chose que des caractères latins (par exemple
des traductions en russe, grec, arabe ou hébreu qui sont TOTALEMENT
corrompues par ces vieux navigateurs web incompatibles et par
l'absence de leur détection ou de solution de contournement par un
support Javascript remplaçant leur fonction javascript
encodeURIcomponent() prédéfinie mais complètement boguée).
Pour la viabilité à long terme des données OSM, il est hautement
souhaitable que les mises à jour effectuées sur la base ne se
contentent pas seulement de mentionner le nom et la version du
logiciel d'édition utilisé, mais aussi la plateforme sur laquelle elle
est exécutée (pour JOSM : indication du type de machine Java et sa
version ; pour rawedit : indication du type de navigateur, sa version
et le type d'OS, sous une forme abrégée si le "User-Agent" est trop
détaillé, mais suffisante par exemple "IE6.x;Win95", voire aussi le
jeu de caractères systèmes sur les versions de Windows avant XP).
Bien sûr on pourrait détecter les changeset des utilisateurs de ces
vieilles versions, mais je ne suis pas convaincu que ce soit des
erreurs volontaires de ces utilisateurs, qui peut-être n'ont pas
d'autre moyen de contribuer avec leur matériel ou logiciel et ne sont
pas assez calés pour installer ou utiliser un autre OS dessus, ou bien
ne le peuvent pas (matériel utilisé seulement en prêt, tel quel, par
exemple depuis un cybercafé, voire même un PC de travail d'une
administration ou d'une bibliothèque française sous-équipée) :
Au lieu d'exclure ces utilisateurs, leur fournir un support très
amélioré avec jQuery (qui fournit de nombreuses fonctions de
contournement très efficaces et bien optimisées) serait nettement
préférable (et peut-être aussi quelques contrôles de validité et
cohérence du côté du serveur Backend, voire même depuis le serveur
Frontend pour éviter certaines modifications qu'ils ne peuvent pas
effectuer sainement, par exemple si un élément contenait du russe ou
de l'hébreu, et que leur navigateur ne supporte pas leur codage).
D'ailleurs tout ce second point n'est pas spécifique à Osmose/rawedit
mais devrait aussi concerner Potlatch, et tout autre éditeur OSM
utilisable en ligne dans un navigateur : identifier les navigateurs
utilisés et les tracer dans les modifications enregistrées avec ces
éditeurs en ligne, est indispensable pour détecter et classer les
problèmes et pouvoir les résoudre correctement et tester les solutions
possibles.
C'est autant une assurance qualité que de stabilité de la base, qui
permettra aussi à des outils automatiques de détecter les anomalies
enregistrées et éventuellement permettre de les corriger ou de les
restaurer "après coup" (le temps de trouver des contournements
viables).
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
