«DOM Level 3 Core» et «DOM Level 3 Load and Save» deviennent recommandations

08/04/2004

Né en 1997, le groupe de travail DOM termine son travail de spécification des API permettant la manipulation de documents XML et HTML. Le niveau 3 enrichit les précédentes versions pour offrir un support complet de XML 1.0 et des espaces de noms. Il offre également la lecture/sauvegarde de documents XML et la possibilité de mélanger les implémentations sous-jacentes.

Le groupe de travail DOM (Document Object Model) annonce deux nouvelles recommandations : «DOM Level 3 Core» et «DOM Level 3 Load and Save». Au programme, un document «Core» plus complet, des évolutions dans les interfaces et les exceptions existantes, de nouvelles fonctionnalités, des nouvelles interfaces et enfin la possibilité d’utiliser une API standard pour enregistrer un document XML.

Un nouveau schéma d’architecture générale des différents concepts relatifs à XML permet d’avoir une meilleure compréhension des API et de leurs dépendances. La spécification ajoute un traitement plus complet des URI (introduction des «DOM URI», support des «base URI» définies dans l’infoset) et offre une correspondance avec l’XML Information Set (décrite dans une nouvelle annexe : Appendix C: Infoset Mapping). Face au nombre grandissant d’extensions de l’API DOM pour des applications XML spécifiques (MathML ou SVG par exemple) et au manque de mécanisme approprié dans DOM Niveau 2 pour les supporter, DOM3 offre un moyen de mélanger des implémentations partielles spécifiques de DOM et d’interroger l’implémentation sur son support d’une fonctionnalité donnée. En complément, DOM3 introduit le mécanisme de «bootstrapping» qui permet à l’application de trouver l’implémentation adéquate selon les fonctionnalités désirées. Une interface de configuration de l’implémentation est également introduite et permet de modifier le comportement de l’analyseur syntaxique, de l’exportation de document dans un flux («sérialisation») ou de la fonction de normalisation du document (Appendix D: Configuration Settings). Enfin, le support des espaces de noms a été amélioré, tant au niveau concept que modifications d’API. A ce sujet, la spécification propose une annexe complète (Appendix B : Namespaces Algorithms) sur la normalisation et la recherche de préfixe.

Pour supporter tous ces changements, la plupart des interfaces classiques (Attr,Document,Element, Node,Text,…) ont été modifiées ou complétées, et, deux nouveaux types, dix nouvelles interfaces et un objet apparaissent. On notera également d’intéressants ajouts dans les API, comme, par exemple, la possibilité de traiter le texte d’un noeud de manière globale (wholeText), évitant ainsi, pour le développeur, la reconstitution du texte d’un élément par le classique parcours des noeuds texte adjacents. L’apparition de données utilisateur semble également intéressante. Elle permet d’associer (setUserData/getUserData) à tout noeud des couples (clé, données). Ainsi, il est possible d’enrichir les noeuds avec tout type d’information complémentaire.

La spécification «DOM Level 3 Load and Save», publiée tardivement, vient combler un manque important dans le traitement des documents DOM. Il s’agit en effet de définir des moyens standard de lire, de sauver et de filtrer des documents XML en passant par le modèle DOM. Il doit également prendre en charge la normalisation complète des documents XML, assurant ainsi le support de XML 1.1.

En tout, seize nouvelles interfaces et une exception sont publiées, toutes (sauf une) préfixées par LS. Les travaux sur JAXP et sur SAX2 ont devancé cette recommandation, et l’ont donc inspirée. Les programmeurs Java pouvaient faire le choix de JAXP pour la lecture des documents XML. Ils s’assuraient ainsi d’une indépendance vis-à-vis de l’implémentation, puisque seules des interfaces sont manipulables dans l’API de Sun. Désormais, ils possèdent une autre alternative pour utiliser une voie standard pour lire du XML : les interfaces du W3C. Xerces, l’analyseur syntaxique de référence de JAXP 1.3 fournit les deux façons de lire un flux XML. Cependant, si JAXP apportait de l’indépendance pour la lecture de document, la sauvegarde n’était pas logée à la même enseigne. La seule façon de faire une sauvegarde standard et indépendance de l’implémentation est de passer par une transformation XSLT identité, ce qui n’est pas vraiment satisfaisant. Toutes les API fournissent bien sûr le service de sauvegarde d’un document DOM, mais à chaque implémentation, une façon différente. Désormais, cette spécification stipule comme utiliser les interfaces pour abstraire le code et rester indépendant. (Xerces fournit également la comparaison pour la sauvegarde). Le 07 novembre 2003, le W3C faisait un appel à implémentation. Une liste des implémentations se conformant à cette recommandation, peu étoffée à ce jour, est maintenue par le W3C. Rappelons que les API sont définies à l’aide du langage IDL et sont donc indépendantes de tout langage de programmation.

Enfin, la collection de tests DOM est mise à jour et inclut les tests des spécifications DOM3 «Core», «Load and Save» et validation.

Autres articles :

Sur d’autres sites :