2.

Le document XML

2.1 Rôle du document XML

Une entreprise fournit des services dont la production nécessite généralement plusieurs étapes. À chaque étape, des informations
peuvent être produites et/ou consommées. Le rôle de l’informatique est d’offrir un cadre de stockage et de traitement de l’ensemble de
ces informations. Pour être comprise, toute information doit être formalisée, c’est-à-dire représentée en respectant certaines règles. Le
choix des mots, l’ordre des mots, etc., tout cela a du sens pour les acteurs de l’entreprise, qu’ils soient humains ou logiciels. Un
document XML sert alors de vecteur à l’information : c’est une manière universelle de représenter des données et leur sens dans un cadre
précis.

Considérons l’exemple d’une entreprise, organisée en différents services, qui demande à un cabinet externe de réaliser des bilans de son
activité. Ces bilans peuvent influencer le fonctionnement de plusieurs services, chaque service ayant ses particularités. Le cabinet
fournit alors un document XML contenant ces bilans. Ce document est ensuite traité par un logiciel qui établit un résultat personnalisé
pour chaque service et propose également aux utilisateurs des fonctions de recherche et d’analyse.
2.2 Le document XML : orienté document ou données ?

Lorsque les données sont élaborées par des êtres humains, on dit que les fichiers XML produits sont orientés document. Lorsque les
données sont construites automatiquement par des programmes, on dit que les fichiers XML sont orientés données. Un fichier XML
orienté document peut être, par exemple, un livre, un article, un message... Un fichier XML orienté donnée est, par exemple, un
sous-ensemble d’une base de données. Il faut noter que l’élaboration des fichiers XML nécessite des moyens de contrôle et
d’édition plus ou moins sophistiqués. On n’utilisera pas pour fabriquer un ouvrage en XML, un éditeur trop rudimentaire (comme le
bloc-notes sous l’environnement Windows). L’édition des documents XML sera abordée dans ce chapitre à la section L’édition de
document XML.
2.3 La circulation XML : notion de bus
Les données informatiques circulent aussi bien en interne, dans l’entreprise, que vers l’extérieur, auprès de services et de partenaires
externes. L’étendue de cette circulation rend le format de données d’autant plus important que chaque acteur peut disposer de
plates-formes d’exploitation différentes. Le formalisme XML neutralise les différences par un consensus de stockage, la plupart des
langages de programmation étant à même de traiter tout type de document XML. Les caractères Unicode constituent également un
moyen de garantir la neutralité des données transportées.

2.4 Structure et validation d’un document XML

On associe à un document XML un schéma, qui peut être vu comme le schéma d’une base de données relationnelle. La validation d’un
document XML garantit que la structure de données utilisée respecte ce schéma. On peut faire l’analogie avec le respect des
règles d’orthographe et de grammaire d’une langue. Les documents XML qui circulent doivent ainsi être en accord avec ce schéma pour
être acceptés par la plate-forme. Dans le cas contraire ils sont rejetés et doivent être refaits. Lorsque les flux d’échanges sont denses, la
validation peut présenter pour inconvénient de consommer des ressources. Il est difficile de raisonner pour tous les cas, mais la validation
peut être considérée comme incontournable à certaines étapes de préparation du cadre d’exploitation. Lorsque les flux sont considérés
comme stables, il est alors possible de pratiquer une forme d’assouplissement des règles dans l’optique d’améliorer les performances.
2.5 Transformation et adaptation d’un document XML

Un document XML peut être transformé ; il n’est pas figé par un émetteur mais peut suivre, par analogie avec les ateliers de production,
différentes étapes de modification. Le format XSLT (eXtensible Stylesheet Language Transformation) est un moyen pour
adapter un document XML à un autre format XML. Ces processus de transformation sont cependant coûteux et doivent répondre à un
besoin. Conduire des transformations en cascade peut être davantage pénalisant que de modifier les logiciels qui génèrent les
documents XML, tout dépend de la réactivité souhaitée. Avec XSLT, on peut parfaitement imaginer exécuter la nuit des programmes
batch qui réalisent ces générations de documents, l’une des générations possibles étant dans un langage de présentation comme
XHTML ou bien XSL-FO (avec indirectement PDF, RTF...).
Par exemple, une société dispose d’un ensemble de produits. Ces produits sont présentés à la fois sur leur site Internet, dans un
catalogue, et dans un logiciel interne pour les salariés… Le formalisme XML peut tisser un lien entre ces différents médias, les données
étant au cœur de l’activité, la présentation n’étant plus qu’un processus de transformation.
2.6 Circulation des documents XML et workflows
Les flux de données (workflows) existants vont être petit à petit remplacés par des workflows XML. Les fichiers XML vont circuler,
s’enrichir au fur et à mesure de ces déplacements, être contrôlés, puis être présentés aux différents acteurs de l’activité
(commerciaux, clients...).

Prenons l’exemple d’un parc de machines équipées d’automates dont on souhaiterait contrôler l’activité. Comme il n’est pas possible de
passer derrière chaque machine pour vérifier les opérations effectuées, un programme de type agent (un programme qui agit de façon
autonome) recueille les informations et les envoie au format XML à une borne de supervision.
2.7 Les bases de données
Les bases de données étant incontournables dans les systèmes informatiques actuels, nous allons, dans les paragraphes suivants, donner
quelques points de repère quant à leurs relations avec XML.

2.7.1 XML et les bases relationnelles

Puisqu’il structure des données selon un schéma fixé, le formalisme XML peut-il remplacer les bases de données relationnelles telles que
nous les connaissons ? La réponse est clairement non et c’est même le danger d’une mauvaise utilisation du formalisme XML. Un
document XML est un fichier texte ; il n’est optimisé ni en espace ni pour les manipulations que l’on peut opérer sur ce type de fichiers. Un
document XML pourrait être davantage perçu comme une partie d’un système d’information, car il résout un problème de circulation de
l’information à un moment donné. Il n’y a pas de raison que les bases de données relationnelles ne soient pas gérées à l’avenir comme
aujourd’hui. Tout au plus, nous pouvons voir l’apparition de solutions complémentaires. Par exemple, le typage des champs d’une table
devrait offrir un typage XML à l’image du blob. La recherche par SQL sera peut-être étendue pour ces types via la
solution XQuery ; le standard SQL ISO travaille sur SQL/XML ( http://www.sqlx.org/ ). Quelques solutions existent déjà ça et là avec SQL
Server ou Oracle par exemple, mais ces solutions n’offrent pas encore de fonctionnement vraiment homogènes.
2.7.2 Les bases « natives » XML

L’autre aspect des relations entre les bases de données et le formalisme XML est l’utilisation de base de données « native XML ». C’est une
solution séduisante pour agglomérer des documents et pouvoir les manipuler plus facilement. Cela peut compenser une certaine faiblesse à
retrouver dans les tables des bases de données relationnelles la correspondance hiérarchique des documents XML. Et puis, les documents
XML étant déjà structurés, l’idée de déstructurer ces documents en vue d’une insertion dans une base semble quelque peu inefficace.
On considère qu’il existe deux formes de bases de données natives : celles gardant le texte du document XML tel quel et celles effectuant
une conversion sous une forme objet (comme DOM, qui est une standardisation objet d’un document XML). Il est certain que la deuxième
forme peut s’appuyer sur des bases objets voire relationnelles (tables pour les éléments DOM : éléments, textes, commentaires...). Vous
trouverez à l’adresse http://www.rpbourret.com/xml/XMLDatabaseProds.htm quelques bases de données natives, avec deux formes
d’implémentation, Open Source ou propriétaire. Parmi les bases disponibles, citons Tamin
o(http://www.softwareag.com/Corporate/products/tamino/default.asp ) en propriétaire, ou bien XIndice ( http://xml.apache.org/xindice/ ) en
Open Source. Je n’ai pas de recommandation particulière à donner. Chaque base a ses avantages et inconvénients, en termes d’API
d’accès, de langage de requêtes, de performance dans les traitements, l’objectif étant d’en mesurer l’efficacité sur un échantillon
représentatif.
2.8 L’édition d’un document XML
L’édition de document XML peut prendre diverses formes, notamment en fonction de sa finalité.

2.8.1 Cas des formats orientés document

Pour réaliser un ouvrage, un article... en XML il n’est pas conseillé d’utiliser un éditeur de texte quelconque. La réalisation de tels
documents impose de se focaliser sur le contenu et non sur la syntaxe du format de document. Pour arriver à alléger la part de ce travail, il
existe des outils qui proposent l’édition en WYSIWYG (what you see is what you get) : l’auteur n’a alors plus l’impression de réaliser un
document XML mais simplement d’utiliser un éditeur graphique (comme Word ou OpenOffice.org). Ces outils utilisent souvent une feuille de
styles CSS (Cascading StyleSheets) qui donne une représentation graphique à telles ou telles parties du document XML. C’est pourquoi,
certains logiciels proposent une édition XML via un navigateur de type Mozilla Firefox ou Internet Explorer. Parmi les éditeurs Open Source
WYSIWYG, citons Bitflux ( http://bitfluxeditor.org/ ), Xopus ( http://xopus.com/ ), qui utilise Internet Explorer et masque totalement la
syntaxe XML, Serna ( http://www.syntext.com/products/serna/index.htm ), qui effectue un rendu à la frappe par XSLT et un sous-ensemble
de XSL-FO et XMLMind, qui s’appuie sur des feuilles de styles ( http://www.xmlmind.com/xmleditor/ ).
2.8.2 Cas des formats orientés données
Dans ce type de format, il n’y a pas de représentation facilement utilisable pour l’être humain, l’idéal étant de passer par une application
qui masquera la localisation des données.

a. Édition avec un formulaire

Certaines solutions visent à analyser les schémas des fichiers XML pour générer un formulaire de saisie. Cela peut être intéressant lorsque
ce formulaire est disponible via un navigateur.
Parmi les éditeurs proposant cette solution, citons EditLive! ( http://www.ephox.com/ ) et Microsoft, avec InfoPath
(http://office.microsoft.com/en-us/infopath/default.aspx ).

b. Éditeurs plus généralistes

Les éditeurs généralistes sont une autre forme d’éditeurs qui s’adressent plutôt à des techniciens. Il existe de nombreux produits, qui
offrent tous la validation et la transformation. Ils se démarquent par certaines facilités.
Le plus connu est l’éditeur XMLSpy ( http://www.altova.com/ ). Ce logiciel a gagné en réputation avec son éditeur de schémas W3C
WYSIWYG. Il dispose également d’une édition par grille. En dehors de cette facilité, l’interface est quelque peu vieillotte et offre peu
d’assistants à la frappe.
Stylus Studio est un autre éditeur proche de XMLSpy ( http://www.stylusstudio.com/ ). Cette application a une certaine réputation pour
son éditeur XSLT semi-WYSIWYG. En dehors de cette facilité, l’édition manque souvent d’assistants et l’interface manque d’ergonomie.
EditiX ( http://www.editix.com/ ) est un éditeur qui offre une vérification syntaxique à la frappe. Une arborescence est à tout moment
synchronisée avec le texte, ce qui facilite grandement la navigation. L’éditeur n’offre pas de mode WYSIWIG mais contient de nombreux
assistants en fonction des documents édités. C’est cet éditeur que nous avons utilisé pour réaliser les travaux pratiques de cet ouvrage.
Vous disposez d’une version d’évaluation de 30 jours ( http://www.editix.com/download.html ).
XMLCooktop ( http://www.xmlcooktop.com/ ) est l’éditeur gratuit le plus connu. Attention, car s’il peut suffire pour des tâches XML
simples, ses limitations et l’absence de maintenance (abandon du développement annoncé par l’auteur) rendent son utilisation délicate
dans un contexte professionnel.
XMLNotepad 2007 ( http://msdn.microsoft.com/xml ) est un éditeur gratuit mis à disposition sur la plate-forme Windows. Il semble
intéressant pour des documents de grandes tailles mais offre très peu d’aide à la saisie.
2.9 Outils pour manipuler les documents XML

2.9.1 Les parseurs XML

Un parseur a pour rôle d’analyser le document XML et de servir de lien avec une application de traitement. Il existe des parseurs non
validants qui n’offrent qu’une vérification syntaxique et des parseurs validants qui offrent également le support des DTD/schéma
W3C. Sur ces deux catégories de parseurs se greffent principalement deux catégories de services : un service événementiel, qui ne vise
pas à représenter un document XML dans son intégralité, de type SAX (Simple API for XML), par exemple, et un service objet, qui permet
de représenter un document XML sous une forme objet, de type DOM (Document Object Model), par exemple. Dans le premier cas, la
représentation du document n’est que partielle, alors que dans le second cas, elle est complète. Ces deux méthodes ont leurs avantages
et inconvénients. Citons seulement la consommation mémoire et la facilité des traitements (requêtage...). Ces concepts seront étendus
dans le chapitre dédié à la programmation.
2.9.2 Transformation d’un document XML
La transformation XSLT d’un document XML fonctionne en complément d’un parseur. Il s’agit d’une API qui réalise le passage d’un
document XML vers un document texte (souvent au format XML lui aussi). La plupart des moteurs de transformation ne gèrent
que la version XSLT 1.0.
Le toolkit MSXML de Microsoft ( http://msdn.microsoft.com/ ) supporte la version 1.0.
Le groupe Apache gère le projet Xalan ( http://xalan.apache.org/ ) pour Java et C++ avec support de la version 1.0.
Saxon est un projet Open Source avec également une licence commerciale. Il fonctionne pour Java et .NET et gère les versions 1.0 et 2.0.
Sablotron est une implémentation en C++ de la version 1.0 ( http://www.gingerall.org/sablotron.html ). Il peut être employé sous forme
d’extension en PHP, Perl, Pascal…

2.9.3 Le format XSL-FO

XSL-FO (Extensible Stylesheet Language Formatting Objects) est un langage de présentation pour différents formats (PDF, RTF...).
Il y a peu d’outils à l’heure actuelle capables de réaliser les transformations XSL-FO. Une première solution propriétaire est Ecrion (
http://www.ecrion.com/ ). Elle gère en sortie les formats PDF et PostScript.
Une autre solution propriétaire est XEP de RenderX ( http://www.renderx.com/ ). Elle gère en sortie les formats PDF et PostScript.
La seule solution Open Source est probablement FOP (Formatting Objects Processor) du groupe Apache (
http://xmlgraphics.apache.org/fop/ ). Elle gère en sortie les formats PDF, Post-Script et RTF.
2.9.4 Le format SVG

SVG (Scalable Vector Graphics) est un langage de description des dessins en 2D. Il existe quelques plugins pour les navigateurs, dont
une intégration native avec Firefox 2.0, le plus connu étant SVG Viewer de adobe ( http://www.adobe.com/svg/viewer/install/
main.html ). Attention cependant, l’éditeur annonçant la fin du support pour 2008.
On retiendra comme implémentation Open Source le projet Batik pour Java ( http://xmlgraphics.apache.org/batikl ) du groupe Apache.