Comments on libxml2 et maux de tête

tartaglia (2010-04-13T20:10:08Z)

Ruxor: mal de tête: relis, des Drs Guillotin et Louis: Des migraines et des différentes manières de les guérir.
Référence: l'Enfer de la BN.

Couard Anonyme (2010-04-11T21:01:38Z)

Arrete de faire ta chochotte et ecris ton propre langage de manipulation de XML (avec un compilo compilant vers Scheme en continuation passing style).

Conscrit neuneu (2010-04-10T07:18:56Z)

Un coup de filtrage à la fin à l'aide d'expressions régulières ne suffirait-il pas?

ushu (2010-04-09T06:54:34Z)

@joel: ne rigoles pas avec Basic… Un très sérieux chef de projet IT de ma boite m'expliquait la semaine dernière qu'on aurait moins de problèmes avec notre application Web n-tiers si on l'avait écrite en Exel/VBA…

joel (2010-04-09T01:12:30Z)

Evidemment que tu as des problèmes, tu aurais du écrire en Basic.

FlorentR (2010-04-08T18:00:45Z)

Ruxor → Tu as raison, xml.dom n'est pas une implémentation de DOM, mais une
interface vers des implémentations de DOM parmi lesquelles on compte
xml.dom.minidom et 4Suite.

La fonction xml.dom.getDOMImplementation() que tu mentionnes et qui est
définie dans /usr/lib/python3.1/xml/dom/domreg.py va chercher une
implémentation qui-va-bien (en fonction du nom ou des features réclamées) dans
ce dictionnaire :

well_known_implementations = {
'minidom':'xml.dom.minidom',
'4DOM': 'xml.dom.DOMImplementation',
}

D'autres implémentations peuvent s'y rajouter, mais c'est ainsi dans la lib
standard de Python 3.1. En cherchant un peu, j'ai trouvé que 4DOM n'est autre
que 4Suite (ou une partie de 4Suite), donc effectivement rien de nouveau ici.

Il reste une implémentation Python de DOM qui n'a pas été mentionnée ici, dont
j'ai découvert l'existence au cours de mes petites recherches Google : pxdom.

<URL: http://www.doxdesk.com/software/py/pxdom.html >

« Complete support for the DOM Level 3 Core and LS Recommendations. Passes all
applicable level1-level3 tests in the DOM Test Suite at the time of writing,
modulo a few suite flaws (see W3 Bugzilla) »

(Je n'ai aucun avis sur sa qualité)

Bon. Si rien de tout ça ne convient, il te reste encore la possibilité de
faire ton blog en TeX et générer le XHTML avec \write, hein. Ça ne sera pas
pire qu'avec Perl. ;-)

xavierr (2010-04-08T16:56:37Z)

Ruxor: Arf non même pas une tentative de troll. Je me désole simplement du fait qu'il n'y ait par exemple aucune façon raisonnable du coder une bête page web statique.
XHTML est probablement la chose qui se rapproche le plus "d'une façon raisonnable de coder une page bête web".

C'est un arbre codé en texte avec des balises et on a la possibilité de définir des espaces de noms. La validation de ces documents est toute aussi triviale que stricte. La belle affaire.
Le format est très simple donc il est facile de le transformer de travailler avec…sauf que par exemple xslt était probablement la pire façon d'exprimer la convertion de XML vers autre chose. Ce n'est qu'un exemple.

C'est un sac de nœuds…comme tu le dis.
C'est un superbe échec car, en pratique, il n'y a pas une seule lib fichue de gérer correctement toutes ces complications (ou, du moins, il n'est pas trivial de trouver (en 5min) LA lib qui permet de faire ce qu'on veut avec ceformat trivial dans un lagage non marginal).
C'est beau…ca donne du boulot à des tonnes d'ingés…

Ruxor (2010-04-08T14:54:26Z)

FlorentR → J'ai peut-être été induit en erreur par la comparaison avec Java, mais il me semble que ce que contient xml.dom est juste une interface, et l'implémentation du DOM renvoyée par défaut par xml.dom.getDOMImplementation() est justement celle de minidom. Il y en a d'autres, mais ce sont celles dont on a justement parlé (4suite, ou libxml2).

Et oui, l'essentiel de mes problèmes vient d'exigences très strictes : un document XHTML 1.0 doit pouvoir être servi *à la fois* comme du XML (valide selon la DTD du XHTML 1.0) *et* comme du HTML-soupe-de-tags, ce qui impose d'autres contraintes bizarres (par exemple, les balises vides doivent être écrites <br /> avec une espace avant le slash et pas <br/>, et d'ailleurs la liste des balises à écrire comme ça est très précise ; les sections <script> et <style> doivent être embarquées dans une section CDATA, qui doit être commentée selon les règles de commentaire du langage en question, JavaScript ou CSS, etc.). La libxml2 sait faire ça très bien, du coup, si je l'abandonne à cause de ses limitations sur les namespaces, ce sont ces bouts-là qui vont me poser problème.

Et oui, les sections CDATA sont importantes dans le <script> et le <style>, même éventuellement avec des navigateurs modernes, à cause de l'épineuse question du type MIME sous lequel on sert le document : si on sert à Firefox du XHTML sous le type text/html, il le digère comme de la soupe de tags, alors que si on lui sert sous le type application/xhtml+xml, il le digère comme du XML, et le but est que le document puisse être digéré dans les deux contextes (IE version 8 ne gère toujours pas le application/xhtml+xml, hélas). L'espace avant le slash dans les balises vides, c'était nécessaire pour links, je crois que ce n'est plus nécessaire pour qui que ce soit, mais je n'y mettrais pas ma main à couper.

C'est un sac de nœuds…

FlorentR (2010-04-08T10:33:07Z)

Ruxor →

1) Effectivement, ElementTree n'est pas une implémentation de DOM, donc si tu
te limites à ça… eh bien, il n'y a tout de même pas que xml.dom.minidom, il
y a aussi au minimum, dans la lib standard Python, xml.dom :

<URL: http://docs.python.org/dev/py3k/library/xml.dom.html >

Souffre-t-il lui aussi de limitations inacceptables ? Pour d'éventuelles
autres possibilités, la doc de la lib std est ici :

<URL: http://docs.python.org/dev/py3k/library/index.html >

puis Ctrl-F xml etc.

2) Concernant le support de CDATA par ElementTree, il respecte les standards,
d'après ce que j'en ai lu. Notamment, et contrairement à ce que ton précédent
commentaire laisse penser, CDATA est *parfaitement supporté en entrée* :

- lors du parsing d'un document XML existant :

<URL: http://mail.python.org/pipermail/python-list/2005-June/322714.html >

qui exhibe un comportement tout à fait normal du parser, cf. la réponse de
Fredrik Lundh, l'auteur d'ElementTree, ainsi que celle-ci :

<URL: http://mail.python.org/pipermail/python-list/2005-June/911911.html >

- par inclusion d'une chaîne de caractères arbitraire comme texte d'un élément
via l'API d'ElementTree :

(bon, là, on va voir si ton moteur de blog gère correctement les caractères un
peu exotiques ;-)

~ % python
Python 2.5.2 (r252:60911, Jan 24 2010, 17:44:40)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.etree.ElementTree import Element, dump
>>> elem = Element("pouet")
>>> elem.text = u"Ça c'est du CDATA qui punit sa maman & < > ! % @#PERL_%TU_M'FAIS¤_PAS_£PEUR#@! <![CDATA[ pouet pouet &$ ]]> <- faux CDATA, cette chaîne contient la représentation *interne* du document, or la syntaxe CDATA n'est qu'une convention de représentation externe"
>>> dump(elem)
<pouet>Ça c'est du CDATA qui punit sa maman & < > ! % @#PERL_%TU_M'FAIS¤_PAS_£PEUR#@! <![CDATA[ pouet pouet &$ ]]> <- faux CDATA, cette chaîne contient la représentation *interne* du document, or la syntaxe CDATA n'est qu'une convention de représentation externe</pouet>
>>>

Tout cela est parfaitement valide, puisque CDATA n'est qu'un sucre syntaxique
permettant aux humains d'insérer plus « facilement » certaines chaînes de
caractères dans un document XML — ou de se casser la tête pour rien, les
points de vue à ce sujet divergent — mais ne fait *pas partie du modèle de
représentation (interne) des données* (ce n'est qu'une représentation externe
parmi d'autres, on peut aussi bien utiliser des entity references [comme
&machin;] pour obtenir la même représentation interne).

Ça, c'était pour l'entrée. Concernant la sortie, effectivement les CDATA
fournies en entrée ne sont pas préservées *en tant que CDATA*, puisqu'elles
n'existent pas à proprement parler dans le Document (je veux dire par là, à
nouveau, le modèle de données hiérarchisé, par opposition à une représentation
externe parmi d'autres représentations équivalentes).

Je conçois que ce point puisse poser problème si les pseudo-parsers XML que
l'on trouve dans les « legacy (X)HTML browsers »[1] requièrent une syntaxe à
base de CDATA pour les fragments de scripts et compagnie. Le problème ici
n'est pas vraiment imputable à ElementTree, il est dû au fait que l'on veut
faire manger du XML à un programme qui ne parse pas le XML comme l'indique la
norme…

[1] Mon bouquin sur XML en parle, mais il date un peu ; les versions
récentes d'IE, Firefox et Safari ont-elles tjs ce pb ?

Ruxor (2010-04-07T22:04:35Z)

Ah, xerces a l'air d'être une piste intéressante (je connaissais, mais je croyais que c'était uniquement Java ; c'est entre autres ça qui me faisait dire que j'aurais peut-être dû écrire en Java… s'il y a des bindings Perl, c'est intéressant, pas tant parce que je tienne au Perl, mais si je peux faire un truc mieux en gardant ce que j'ai déjà écrit, c'est tout bonus). Merci pour le pointeur.

Ruxor (2010-04-07T22:01:07Z)

xavier → Belle tentative de troll, mais tu mélanges tout (le XML, les namespaces en XML qui sont une norme à part, les DTD du XML qui sont encore autre chose, le XHTML). Évidemment, si on met tout ensemble, et si on oublie à quoi ça sert pour ne retenir que « c'est un arbre », ça semble un peu trivial (encore que, des bibliothèques capables de gérer correctement des arbres mutables, avec propriétés héritables, de façon efficace, je ne suis pas sûr qu'il y en ait beaucoup, et je ne suis pas certain qu'il n'y ait pas des difficultés théoriques cachées). Les DTD sont effectivement quelque chose de beaucoup trop compliqué, et d'ailleurs on tend à les oublier, de nos jours, sauf pour ce qui est de la compatibilité ascendante, ce qui est justement ce qui rend le (X)HTML pénible (la nécessité de maintenir la compatibilité avec toutes sortes d'horreurs historiques, du SGML à la soupe de tags). Les namespaces en XML sont quelque chose de très utile et séduisant, et pas très difficiles en eux-mêmes, mais le mélange namespaces+DTD, lui, il est redoutable.

FlorentR → ElementTree n'est pas une implémentation du DOM du W3C, et je préfère largement travailler avec le DOM. Mais de toute façon, il lui manque des choses dont j'ai besoin (au moins les sections CDATA, qui sont nécessaires en sortie pour pouvoir mettre du CSS ou JavaScript dans du XHTML en respectant la compatibilité soupe-de-tags, et aussi en entrée parce que j'en ai dans mes documents). 4suite a l'air d'être beaucoup plus proche de ce que je veux (pas Amara, qui est une couche au-dessus qui ne me servirait à rien), mais il est un peu difficile de prévoir, sans tester, si contrairement à la libxml2 il retirera bien les déclarations de namespaces inusitées (le truc c'est que ce n'est pas une erreur d'en mettre, sauf dans le cas précis où on veut faire ce que je veux faire, c'est-à-dire du XHTML valide).

ushu (2010-04-07T21:53:45Z)

Elementtree se base bien sur Expat de James Clark. C'est d'ailleurs ce qui a retardé son portage vers Jython: il a fallu développer un binding pour mapper l'API pyexpat sur la librairie SAX de Java. Mais tout ça est réglé depuis Jython 2.5…

Sinon David as-tu envisagé xerces ? Il semble y avoir un binding officiel pour Perl (XML::Xerces) et c'est vraiment une librairie très (trop ?) complète.

Fred le marin (2010-04-07T18:58:47Z)

C'est horrible.
Mais pas de quoi s'en faire des "NodeList" au cerveau, hein ?!

FlorentR (2010-04-07T18:07:17Z)

Hum, je ne suis pas super pointu en XML, mais il me semble que l'affirmation
concernant Python, à savoir :

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

est, comment dire… fausse. J'ai un peu manipulé du XML avec Python, en
utilisant le package (bibliothèque) ElementTree :

<URL: http://effbot.org/zone/element-index.htm >

À première vue, ce package qui est bien connu des Pythonneux et fourni dans la
bibliothèque standard depuis des années, n'est pas basé sur libxml*
(contrairement à un autre package appelé lxml.etree) ni sur xml.dom.minidom
comme le montre un grep sur le dépôt SVN de ElementTree :

~/src-pastouche/elementtree-1.3a3-20070912 % grep -ir dom *
benchmark.py: from xml.dom import minidom # pyexpat+minidom
benchmark.py: minidom = None
benchmark.py:def benchmark_minidom(file):
benchmark.py: dom = minidom.parse(file)
benchmark.py: print "minidom tree read in %.3f seconds" % (t1-t0)
benchmark.py: del dom
benchmark.py:if minidom:
benchmark.py: benchmark_minidom(file)
benchmark.py: print "=== minidom not available"
~/src-pastouche/elementtree-1.3a3-20070912 %

Le mot "dom" n'apparaît que dans benchmark.py, autrement dit pour comparer les
performances de ElementTree à celles de xml.dom.minidom.

Je ne dis pas que tes problèmes seraient *forcément* résolus avec Python, car
je ne sais pas précisément ce que tu cherches à faire (j'ai l'impression qu'il
s'agit de remplacer des attributs ou éléments "david:monmachin" par une
implémentation XHTML, autrement dit de l'expansion de macros, mais je ne suis
pas sûr) et je ne suis pas très pointu en XML (notamment au niveau des DTDs).
Mais il me semble que tu rejettes d'emblée Python pour une raison totalement
fausse.

De plus, si ElementTree est la bibli Python que je connais un peu pour
manipuler du XML, il y en a clairement d'autres. Je n'ai pas fait
d'inventaire, mais il y a au moins Amara :

<URL: http://www.xml3k.org/Amara >

qui est écrit par un mec qui a priori s'y connaît bien en namespaces XML[1],
et basé sur 4Suite :

<URL: http://4suite.org/ >

… URL qui me renvoie pour l'instant "Service Temporarily Unavailable", donc
je ne peux pas dire si ce dernier s'appuie ou non sur libxml2.

Puisque les namespaces semblent jouer un rôle important dans tes tracasseries,
tu seras sûrement ravi d'apprendre que la page :

<URL: http://effbot.org/zone/element-index.htm >

contient plusieurs liens à ce sujet :

ElementTree: Working with Qualified Names
<URL: http://effbot.org/zone/element-qnames.htm >

+ lien donné en [1]

De plus, la dernière version de ElementTree (1.3, qui date de 2007) comporte
visiblement des changements importants relatifs aux namespaces :

<URL: http://effbot.org/zone/elementtree-13-intro.htm >

et le tutoriel :

<URL: http://effbot.org/zone/element.htm >

pas mal de commentaires à ce sujet aussi (a priori antérieurs à la version
1.3, donc à prendre avec des pincettes).

Si tu es de bonne foi et me donnes un exemple de ce que tu veux envoyer en
entrée et obtenir en sortie, je veux bien regarder comment le faire avec
ElementTree (sans doute pas avant ce week-end), mais si c'est pour FUDer sur
Python en affirmant d'emblée qu'il ne « peut pas », annonce la couleur dès le
début !

[1] Pour avoir écrit :

XML Namespaces Support in Python Tools, Part Three
<URL: http://www.xml.com/pub/a/2004/06/30/py-xml.html >

xavier (2010-04-07T15:30:14Z)

Splendide.
Non seulement XML est un trivialité absolue (coler des info dans un arbre définit par des balises texte) mais "ils" ont aussi réussi à pondre une norme totalement ridicule car N fois trop complexe. C'est tellement mal foutu qu'aucune lib n'est fichue de lire manipuler un fichier XML correctement…
"Ils" ont réussi à merder la spec d'une norme pour définir un arbre à base de balises texte. *bravo*. Fallait le faire. Bel effort.
Les ingé sys/rezo ont un bel avenir devant eux.

Je me demande quand même si XML est une norme plus débile que l'ACPI…ou si c'est le contraire. Dans les deux cas, le KISS est violé, reviolé et rereviolé.

Ruxor (2010-04-07T11:55:20Z)

Touriste → Il n'y a pas (encore) de nouveau moteur. :-( J'avais juste oublié de déclarer le mois d'avril 2010 (ça m'arrive assez souvent, en fait, en début de mois, et le moteur actuel est trop pourri pour détecter ce genre de problèmes).

Arnaud Spiwack (2010-04-07T10:14:25Z)

Le problème, c'est plus probablement la complexité intrinsèque de XML que le langage de programmation hôte. Une idée pourrait-être de s'en extraire jusqu'au dernier moment (où de toute façon il faut cracher du (x)html), mais ça n'est pas forcément une solution qui te paraîtra élégante ou adapté à ton besoin.

Touriste (2010-04-07T09:56:20Z)

Je signale sur le champ un bug dans la nouvelle implémentation du blog : les liens renvoyant de la liste complète des "commentaires récents" vers les articles commentés, ou du titre de l'article vers la page du mois, ne marchent pas à partir du présent article. Précisément la liste des commentaires récents contient un lien vers

http://www.madore.org/~david/weblog/2010-04.html

(la même syntaxe que d'habitude)

qui est pourtant une adresse renvoyant une erreur 404. Je suppose que c'est la création de cette page qui a échoué, que tu n'as pas l'intention de revenir sur le principe d'une page mensuelle ni sur la syntaxe de son adresse.

DH (2010-04-07T06:36:00Z)

Et toute cette avalanche de messages sur forum pour quelque chose qui se contourne en 4 à 5 malheureuses secondes ? C'est presque névrotique à ce point…

Fork (2010-04-07T05:18:54Z)

Courage pour la suite. Je suis impatient de voir si le nouveau moteur aura un effet sensible sur l'interface utilisateur.