Extensible Markup Language - Définition

Outils et processus XML

XML a désormais prouvé qu'il était une syntaxe très générique de balisage, propre à de nombreux usages. Cette réussite s'explique par des implémentations concurrentes de nombreuses interfaces de programmation (API) précisément spécifiées. Comment entre-t-il dans un processus applicatif ?

Pour détailler ces étapes, considérons le processus le plus simple, accessible depuis quelques années dans Internet Explorer ou Firefox. Ces navigateurs permettent de consulter des fichiers dans un XML sémantique (qui ne contient que des contenus, sans présentation), et de les voir comme des pages accompagnées de couleurs et de navigation. Ils sont transformés par le client, à l'aide d'une feuille XSLT. Prenons par exemple le site de Norman Walsh. La source de la page servie ressemble à ceci :

         version='1.0' encoding='utf-8'?>         href="/style/browser.xsl" type="text/xsl"?>         xmlns="http://docbook.org/ns/docbook" xml:lang="en" version='5.0'>          >            >XProc: An XML Pipeline Language>                >      

Ce n'est pas du XHTML (ou du HTML) mais du DocBook. Les navigateurs ne sont pas capables de lire cette grammaire pour lui donner de la présentation. La page apparente est le résultat d'une transformation, signalée au navigateur par l'écriture . Le fichier browser.xsl explique comment transformer du DocBook en HTML. Le processus est immédiat, il est intéressant de le détailler, car on le retrouve dans des applications XML plus complexes.

1. produire : le document DocBook doit avoir été produit ou résulter d'un import ;
2. entrée : dans le navigateur, un parser lit le fichier XML pour construire un objet informatique, et vérifie que le document est bien formé ;
3. transformation : le document DocBook est transformé en XHTML ;
4. inclusions : dans certains contextes, il est possible d'inclure des fichiers qui deviendront des nœuds ;
5. validation : le document peut être validé, pour vérifier que sa structure est conforme au schéma docbook ;
6. sortie : le navigateur s'occupe de rendre le résultat de la transformation en une page pour un utilisateur.

Cette succession canonique d'étapes illustre ce que peut être le tuyau d'un processus XML complet. Elles vont maintenant être expliquées pour montrer comment elles peuvent apparaître dans d'autres contextes applicatifs plus complexes.

Exporter et Produire

Une organisation qui a déjà son système d'informations qui n'est pas basée sur XML peut se demander comment produire du XML. Il existe de nombreuses manières d'exporter et de produire du XML, afin de rentrer dans une chaîne de processus XML.

• Traitement de texte, la plupart des logiciels bureautiques proposent un export XML, quand ils ne sont pas nativement XML (OpenOffice.org, Microsoft Word). Le plus simple est parfois d'enregistrer en HTML, récupérable moyennant un petit traitement. Il suffit de regarder les formats disponibles avec la fonctionnalité Enregistrer sous de son logiciel habituel.
• SQL, la plupart des SGBD proposent un export XML.
• Un éditeur XML est le meilleur moyen de faire produire par un humain un document correspondant exactement au schéma attendu.

Dans le cas en introduction, Norman Walsh utilise un simple éditeur de texte, emacs.

Parseurs et interfaces de programmation (API)

Avant d'entrer dans un processus XML, un contenu doit être « xmlisé ». Cette opération est effectuée par un processeur XML. Les parseurs les plus répandus sont :

• MSXML - Microsoft Core XML Services, le parseur XML Microsoft, 2000-2006, intégré au système d'exploitation Windows, accessible aux langages Microsoft, notamment en JavaScript sur le navigateur Internet Explorer.
• libxml2 - Le processeur XML libre du système d'exploitation linux, accessible en C , Python [2], PHP [3], et en Ruby [4]
• Xerces - XML Java Parser, le parseur XML par défaut d'une machine virtuelle Java, accessible en Java
• Expat - Le parseur XML de James Clark, notamment embarqué par les navigateurs mozilla (firefox).
• VTD-XML

Il en existe beaucoup d'autres, en particulier en Java, adaptés à différents cas particuliers : ouvrir une API plus simple, accepter des documents mal formés comme HTML, traitements plus simples (notamment pour les documents longs).

Une fois « xmlisé », un document est accessible à différents langages, selon des interfaces de programmation standardisées. On distingue généralement l'approche DOM, modèle objet en mémoire, et l'approche SAX, génération d'événements.

• DOM, Document Object Model, constitue un objet en mémoire de la totalité d'un document XML. Cette API permet l'accès direct à tous les nœuds de l'arbre (éléments, texte, attributs), pour les lire, ou les modifier. Il est par exemple très utilisé sur les navigateur web avec JavaScript. Cette norme est écrite par le W3C.
• SAX, Simple API for XML, est une alternative intéressante à DOM pour le traitement de documents longs. Quand un document entre dans un processeur XML, du code SAX peut capturer des événements, comme l'ouverture et la fermeture d'une balise, afin par exemple, d'écrire dans une base de données. À l'inverse, il est possible de générer des événements SAX, par exemple à partir de la lecture d'une base de données, afin de produire un document consommé par une autre étape d'un processus XML.

D'autres API existent, comme JDOM, dom4J (Java), ou StAX. Il n'est toutefois pas nécessaire de « programmer » pour traiter du XML, notamment avec des langages de transformation comme XSLT. Dans le cas en introduction, votre navigateur charge automatiquement le document docbook, et passe le contenu à une transformation xslt.

Transformation

La transformation est l'étape d'un processus XML qui prend un document dans un certain schéma pour le transposer dans un autre espace de noms. L'exemple en introduction permet de bien comprendre l'opération. Soit un document textuel qui ne comporte que du contenu. Il sera nécessaire de lui ajouter au moins de la navigation avant de le diffuser sur Internet ; on en voudra aussi une version imprimée (pdf). La facilité de transformer un document XML, notamment avec XSLT, est une raison importante pour choisir ce format.

Inclusions

Un document XML peut être constitué de plusieurs fichiers. Il y a deux normes actuellement concurrentes.

• les entités externes, issues de SGML, résolues a priori par un parseur validant, avant tout traitement du document.
• xinclude, un élément XML dédié, pouvant être traité comme une étape séparée.

Les spécifications et les implémentations privilégient maintenant xinclude, bien que son adoption ait pu être discutée.

Considérons l'exemple d'un catalogue de produits pour voir les effets de l'un et de l'autre. On aura chaque produit sous la forme d'un document XML, et un document maître qui assemble toutes les références. En entités, cela s'explique ainsi.

                            "articles/article002.xml">        ]>                 xmlns="http://exemple.net/ns">          >catalogue>          &article001;          &article002;        >      

On remarquera que les entités sont déclarées en entête de document, puis appelées par une écriture du type &entité;. Cette syntaxe est initialement prévue pour des raccourcis, afin de factoriser l'écriture de variables comme un nom de produit ou une société. Ce mécanisme a été étendu pour résoudre les problèmes d'encodage en ASCII avant l'Unicode. Ce sont les entités caractère comme é=&#E9;=é. Pour le cas d'une inclusion d'un fichier, cela demande deux déclarations, celle du lien, celle de son appel. Ce moyen reste massivement employé par les sociétés qui ont connu SGML, d'autant que son support est beaucoup plus généralisé que celui d'xinclude.

La résolution a priori des inclusions peut avoir des inconvénients, en particulier pour des documents maître très lourds que l'on peut vouloir travailler sans leur dépendances. Xinclude permet cela, ainsi que de générer ces relations automatiquement (XSLT).

                 xmlns="http://exemple.net/ns"          xmlns:xi="http://www.w3.org/2001/XInclude">          >catalogue>           href="articles/article001.xml">        >      

On retrouve cette évolution vers la modularisation d'XML où l'inclusion devient une étape optionnelle d'un processus.

Validation

La validation est l'opération automatique qui vérifie la conformité d'un document XML à son schéma. Elle a pour but de délivrer des messages comme il n'y a pas de titre au chapitre 5, ou bien, la date de fabrication est dans le futur. La précision et la convivialité de cette vérification dépendent de la syntaxe utilisée.

En SGML, la validation s'effectuait toujours avant l'entrée d'un document XML dans un processus. On parlait de parser validant. Il n'y avait alors qu'un seul langage de validation (les DTDs) déclarés d'une seule manière à l'intérieur du document XML (la déclaration DOCTYPE, Type de document). La pratique a montré que la validation n'est pas toujours nécessaire, et même, contre performante. Dans d'autres cas, plusieurs étapes de validation peuvent être utiles, par exemple, une pour vérifier la structure de l'arbre XML, une autre pour vérifier les liens. L'évolution va vers une étape de validation distincte, déclarée à l'extérieur du document, et gérée selon les besoins du logiciel.

Les parseurs XML gardent l'ancien usage de conserver les bibliothèques logicielles de validation. Cependant la fonctionnalité peut être débranchée, ou appelée séparément. Il existe aussi des bibliothèques uniquement dédiées à la validation. Le déploiement actuel rend la validation XML nativement accessible à la plupart des systèmes, et dans la plupart des langages de programmation.

• MSXML - Microsoft Core XML Services, validation DTD et XML Schema.
• libxml2 - Validation DTD et Relax NG (le support XML Schema est partiel, surtout pour le typage de données au sein de Relax NG).
• Xerces - XML Java Parser, validation DTD et XML Schema.
• Jing - a Relax NG validator in Java, un validateur qui n'est pas un parseur pour Relax NG et Schematron.
• XSLT - Une transformation XSLT permet une validation très précise sur un type de document, c'est couramment utilisé dans une application web pour rendre à l'utilisateur des messages plus conviviaux, cet outil suffit aussi pour utiliser une implémentation Schematron.

Sorties

Dans le cas en introduction, le navigateur est le consommateur final de XML, sous la forme de xhtml. Chaque langage XML de représentation (XSL-FO, SVG…) peut être consommé par une application utile à l'utilisateur. Certains formats peuvent être traités par plusieurs bibliothèques logicielles.

• (en) Apache Batik, API Java traitant des documents SVG (exemple : export JPG, PNG).
• (en) FOP, le sérialiseur XSL-FO d'Apache
• (en) XEP, processeur XSL-FO et SVG commercial, RenderX.

« Tuyaux » (XML Pipeline)

Les étapes décrites plus haut sont en cours de normalisation par le W3C (XML Processing Model Working Group). La terminologie est officialisée. Ces idées ont déjà des implémentations concurrentes dans plusieurs frameworks (Apache Cocoon, Orbeon Presentation Server…). L'idée de tuyaux XML existe avant d'avoir été spécifiée.

Un tuyau est une entrée (Input Document), une sortie (Output Document), et une chaîne d'étapes (Step). Ces étapes traitent un flux XML (XML Information Set, Infoset [5]). La notion de flux d'information n'est pas spécifique à XML, on la retrouve à grande échelle dans l'informatique réseau, ou très simplement en ligne de commande Unix, avec la barre verticale, pipe en anglais). L'originalité réside dans la structuration propre à XML. Les octets traités par ces tuyaux sont des documents structurés. Les étapes sont standardisées et combinables. Elles sont définies par des composants (components) paramétrables (parameter), le tout en XML.