Attention, voici un rant énervé.

On pourrait croire, a priori, que le format XML est prévu pour que tout outil XML soit capable de lire un fichier XML et travailler dessus sans forcément avoir accès à d'autres contenus. C'est oublier, cependant, qu'un fichier XHTML, par exemple, peut faire appel à des entités (é etc), lesquels sont définis dans un fichier externe référéncé par la DTD référencée par l'en-tête XHTML. Votre outil XML voudra donc typiquement télécharger la DTD et les listes d'entités, ce qui va bien évidemment échouer si vous n'avez pas de connexion Internet, et sera de toute façon lent. La documentation typique des outils XML n'explique pas clairement comment résoudre ce problème pourtant assez immédiat (oui, je sais, il faut définir un « catalogue » et persuader l'outil de l'utiliser). Ainsi, récemment je me demandais pourquoi un lecteur de XML que j'utilisais était si lent, et j'ai compris que ce chameau rechargeait la DTD et les entités XHTML à chaque fichier lu ! Et évidemment la documentation ne documente pas ce gag, j'ai dû chercher dans Google, des blogs et des FAQ.

Mémo 1 : quand votre bibliothèque contient un gros piège dans lequel l'utilisateur risque de tomber, documentez-le. Évidemment, si on lit très attentivement la documentation, on peut construire une solution au problème, mais c'est du sadisme que d'attendre que l'utilisateur tombe dans le piège et réinvente la roue pour s'en sortir. (J'enfile les métaphores foireuses, je sais.)

Des structures arborescentes, c'est bien. Cependant, tous les arbres construits sur les mêmes identificateurs de nœuds n'ont pas forcément de sens (ça n'a pas exemple pas de sens, pour un logiciel de fichier client, de mettre la fiche client dans le champ contenant les emplettes du client, au lieu de l'inverse). Pour cela, on veut définir les structures acceptables. En informatique, on sait très bien faire cela par exemple avec des grammaires hors contexte (LL, LALR(1)). Pour XML, il y a 3 (j'ai bien dit 3) formats de spécification : les DTD (un format assez illisible), XML-Schema et Relax-NG. Pour tout arranger, tous les outils et bibliothèques ne savent pas valider les contenus avec tous les formats. Certains sont par ailleurs buggués : j'ai ainsi eu un échange de courriers électroniques avec les concepteurs de OpenOffice.org parce que les fichiers OpenDocument que leur logiciel produisaient ne passaient pas dans le validateur Relax-NG que j'utilisais.

Mémo 2 : ne pondez pas n formats qui font en gros la même chose, et documentez-les de façon lisible et utilisable.

Parlant de OpenDocument, j'ai trouvé la documentation de ce format particulièrement illisible. Visiblement, l'idée de mettre des exemples concrets et compréhensibles (même en section non normative) n'atteint pas les comités de normalisation.

Soyons francs : les arbres, ce n'est pas sorcier, l'écriture linéaire d'un arbre par parcours récursif non plus, les grammaires sont connues depuis longtemps, pourquoi avoir fait si compliqué ?