XOM : XML Object Model 1.0
06/01/2005
XML est définitivement une affaire de personnalités ! Après Michael Kay et son processeur Saxon, Tim Bray et genX, Daniel Veillard et libxml, Elliotte Rusty Harold annonce un nouveau parseur Java XML : XOM 1.0.
Elliotte Rusty Harold est un expert des technologies XML. Auteur de plusieurs ouvrages sur le sujet, il s’est penché de près sur les avantages et les inconvénients des différentes API permettant de manipuler des documents XML. Sa conclusion est assez sévère : les API XML (comme SAX ou DOM) ont été écrites par des programmeurs experts qui découvraient XML. Ainsi le produit de leurs travaux n’était pas, toujours selon Elliotte Rusty Harold, d’une grande qualité. Cette arrogance, l’auteur la justifie par le fait qu’elle est construite sur une forte expérience du domaine et sur son expertise démontrée au fil des ans.
Ainsi, il a passé en revue les quatre types d’API : événementielles type push (comme SAX), événementielles type pull (comme XMLPull ou StAX), celles à base de représentation arborescente (comme DOM, JDOM, etc) et enfin celles dites de «Data Binding» (comme Castor ou JAXB). De toutes ces observations, Elliotte Rusty Harold en a tiré une conclusion. Toutes présentent suffisamment d’inconvénients pour laisser la place à une nouvelle qui tenterait d’être plus pertinente. Les objectifs qu’il fixe pour XOM sont prometteurs !
- produire du XML correct. XOM est une implémentation de XML 1.0 focalisée sur l’impossibilité de produire du XML mal formé,
- facile à utiliser grâce à une API intuitive évitant de consulter fréquemment la documentation,
- facile à apprendre : un seul paquetage nu.xom pour toutes les fonctionnalités principales. Tout ce qui se trouve en dehors est optionnel et peut-être ignoré par un utilisateur débutant. XOM ne doit pas surprendre, les méthodes ont des noms explicites. Si XOM surprend, la surprise doit venir de XML lui-même et non de cette mise en oeuvre Java,
- rapidité d’exécution et taille en mémoire acceptable : ces aspects ne sont clairement pas des priorités pour l’auteur qui préfère se concentrer sur les points précédents, pour offrir un ensemble stable qu’il pourra optimiser par la suite.
Pour construire cette API, Elliotte Rusty Harold a conjugué principes de conception objet, principes liés à Java et à la nature intrinsèque de XML. Ainsi les classes (il n’y a pas d’interfaces, l’auteur les jugeant inadaptées pour une librairie efficace) possèdent des pré-conditions et des invariants sur lesquels l’utilisateur ne peut passer outre. Seules les méthodes ne mettant pas en péril la conformité vis-à-vis de XML peuvent être surchargées. Et à l’instar des réflexions sur DOM Traversal, XOM n’implémente pas non plus le design pattern Visiteur (des données d’une classe pouvant être manipulées de l’extérieur sans contrôle). Car l’obsession de l’auteur est bien d’assurer l’impossibilité pour un utilisateur de produire un document XML mal formé.
Contrairement aux idées reçues, XOM n’a rien à voir avec JDOM. L’auteur a participé au développement de ce dernier et reconnaît avoir beaucoup appris techniquement. Cependant, en désaccord avec de nombreux principes de conception dans JDOM, il hésita à s’en servir de base pour en créer une nouvelle version. Finalement, il abandonna l’idée et repartit d’une feuille blanche. Si XOM est écrit en Java, l’API se distingue donc de JDOM ou de DOM4j en laissant certaines fonctionnalités inhérentes au langage Java volontairement de côté. Ainsi les classes sont pas «serializable» car XML est lui-même un format offrant cette fonctionnalité et est nettement plus inter-opérable que celui de la «serialisation» java. La notion de classe «Cloneable» est également laissée de côté au profit du copie constructeur classique. Les listes de noeuds utilisent une représentation interne à XOM et ne se basent pas sur les «List» Java, jugées pas assez performantes (notamment vis-à-vis des threads). Enfin, les principes de programmation objet sont respectés puisque les accesseurs en écriture ne retourne pas l’objet lui-même mais le type «void». Ce qui contraste avec les facilités de JDOM, qui permet notamment d’écrire, en une seule ligne
new Element(”html”).appendChild(new Element(”head”))
Les fonctionnalités de XOM 1.0 sont les suivantes :
- libre, pure Java
- un nouveau modèle de document XML 1.0. XOM ne supporte pas XML 1.1 (délibérément), qualifié d’abomination par l’auteur
- support de XInclude
- support de XML canonique (traduction française)
- des ponts vers SAX et DOM
- support de TrAX pour les transformations XSLT
Elliote Rusty Harold prévoit les améliorations suivantes :
- possibilité de naviguer dans l’arbre
- support de XPath 1.0
- filtre (un des plus de JDOM)
- support des catalogues (pour les DTD)
- support de XML encryption et XML digital signatures
Pour faciliter son utilisation, l’auteur fournit un tutorial. Par ailleurs, l’absence du support de XPath et le besoin de faire des requêtes sur les documents ont poussé Wolfgang Hoschek à développer Nux, une extension permettant d’utiliser XQuery (et donc XPath 2.0) avec XOM. Cette mise en oeuvre utilise Saxon-B comme moteur de requêtes.
Si XOM est un logiciel libre, il n’en reste pas moins qu’il est l’oeuvre d’un développeur déterminé à garder le contrôle de son oeuvre. Elliotte Rusty Harold insiste beaucoup sur ce point. Même s’il est ouvert aux critiques et suggestions, il proclame XOM comme une république bananière : «XOM is a more-or-less benevolent dictatorship, not a democracy. I am the only committer. This is my API, and it reflects my thoughts and desires». Cela a au moins le mérite d’être très clair ! XOM est disponible depuis le site xom.nu sous licence LGPL.
Autres articles :