Loi de Hofstadter : Les choses prennent toujours plus de temps que prévu, même quand on tient compte de la loi de Hofstadter.
Quand je me suis mis mis en quête
de remplacer le moteur de ce blog, il y a déjà un mois (traduire : ça
fait un mois que je travaille là-dessus dès que j'ai du temps libre),
je pensais que ce serait plutôt facile. C'était sans compter le
principe ci-dessus, et surtout le fait général qu'à chaque fois que je
commence à utiliser un programme ou une bibliothèque qui,
superficiellement, de loin, a l'air bien pensé et bien écrit, je me
rends compte que tout n'est que façade, que c'est bourré de bugs ou de
limitations obscures et que rien ne marche comme annoncé, qu'il y a
généralement des petites crottes de ragondin partout. C'est le cas,
spécifiquement, de
la libxml2 et (par voie
de conséquence) de son enrobage
Perl, XML::LibXML.
En l'occurrence, ce qui me cause le plus de maux de tête, c'est la
façon dont sont gérés
les namespaces XML.
(J'utilise un namespace à moi pour séparer les balises que j'ai
inventées, dans le code que je tape, des balises HTML
— c'est justement à ça que servent les namespaces.)
Superficiellement, la façon dont la libxml2 procède est
très bien : plutôt que d'imposer que le programmeur attache lui-même
les attributs xmlns nécessaires aux endroits voulus
(comme ce serait le cas en principe avec une implémentation conforme
du DOM),
la libxml2 attache elle-même les attributs comme il faut
aux endroits où il faut. L'ennui, c'est que parfois ces attributs
cessent d'être nécessaires, ou parfois on est obligé d'en ajouter à
cause de limitations bizarres de la bibliothèque, et alors c'est la
croix et la bannière de les retirer. Or le
standard XHTML
ne m'autorise pas la fantaisie d'avoir des
attributs xmlns:inutile="http://www.example.tld/mon/namespace/a/moi/"
qui ne servent pas — on a le droit (pour êre valide) à
exactement un attribut xmlns sur tout le
document, c'est sur l'élément <html> à la racine,
point-barre. Enfer et damnation ! J'ai passé un temps infini à
contourner ce
bug, qui n'est pas grave en lui-même, mais qui est rendu gênant
par celui-ci,
après avoir aussi trébuché
sur ce
bug (corrigé dans la dernière version), et m'être lamenté
qu'il n'y
ait pas une autre façon de faire. La seule façon que j'aie
finalement trouvé pour contourner (pas résoudre, mais contourner) ce
genre de problèmes, c'est de recopier tout
l'arbre DOM juste avant de le sortir, de façon à
obliger la bibliothèque à ne recopier que les déclarations de
namespace qui servent vraiment (et, on l'espère, une seule) : ceci
coûte un temps délirant et vraiment inacceptable (environ quatre à
cinq secondes pour traiter mon blog, sur une machine relativement
puissante).
Évidemment, je m'expose à un concert de protestations comme quoi
j'aurais dû écrire en <insérez
ici votre langage de programmation
préféré>. Bon, pour une fois, on ne pourra pas me dire Python,
parce que l'implémentation du DOM XML
de Python, soit elle est aussi basée sur la libxml2, et
elle souffre exactement des mêmes défauts, soit
c'est xml.dom.minidom qui a d'autres limitations encore
plus douloureuses. Par contre, il est possible que j'aureusse
dû [←ceci est un subjonctif conditionnel passé, ne cherchez pas]
utiliser Java ou C#/Mono. Toujours est-il que je ne sais plus où
donner de la tête.