Introduction

La métaphore du document est omniprésente dans les interfaces utilisateur graphiques qui peuplent nos écrans depuis la banalisation des systèmes de fenêtrage amorcée par le lancement du Macintosh d'Apple Computer en 1984. À l'origine, l'idée forte, reprise par Apple à Xerox, est d'associer une catégorie de documents à une application qui permet de les produire, de les modifier et de les présenter (à l'écran ou sur papier). La feuille de calcul est ainsi associée au tableur, le texte au traitement de texte, le document graphique à l'application de dessin, etc. Ces idées ont évolué au contact d'autres modes opératoires liés aux documents comme le copier-coller ou le glisser-déposer. Les interfaces graphiques qui s'appuient sur ces manipulations simples ont été rendues populaires par le formidable succès de Windows 3.0 de Microsoft dans les années 90, par la généralisation de Motif sur les plates-formes sous UNIX, et, bien sûr, par l'explosion du Web porté par l'Internet. Dans ces interfaces, le document est vu comme un conteneur susceptible de recevoir des objets de natures différentes : des textes, des graphiques, des animations, des sons et des images, des vidéos, voire du code exécutable (applets en Java ou contrôles ActiveX, par exemple). L'application est alors associée à l'objet et non plus au document dans sa totalité.

Le standard OpenDoc, élaboré conjointement par Apple, IBM et Hewlett-Packard au début des années 90, constitue la première incarnation de cette évolution du rôle du document. Bien qu'adopté par l'OMG (Object Management Group) dans la spécification Corba (Common Object Request Broker Architecture), OpenDoc n'a pas connu le succès commercial espéré et, après avoir périclité, a été finalement abandonné par ses promoteurs mêmes. En revanche, on peut avec raison prétendre que cette idée du document comme conteneur est sous-jacente à toute l'évolution de l'architecture de composants logiciels qui sous-tend Windows de Microsoft depuis le DDE (Dynamic Data Exchange) des premières versions jusqu'à l'architecture ActiveX de l'éditeur. L'opération élémentaire du modèle objet COM (Component Object Model) de Microsoft est en effet la composition, c'est-à-dire la constitution de nouveaux objets qui englobent des objets existants. Par comparaison, l'opération élémentaire de l'autre grand modèle objet concurrent de COM, à savoir Corba de l'OMG, est l'héritage au sens des langages de programmation orientés objet qui se prête difficilement aux opérations de composition. En s'appuyant sur COM, le document dans Windows devient naturellement un conteneur - visible mais identique, dans le principe, aux autres conteneurs COM - de composants logiciels. Les versions successives de suites Office de Microsoft réalisent une des premières implémentations de cette métaphore, avec le succès commercial que l'on connaît. Il est tout à fait remarquable de noter que, surpris par l'irruption du Web sur le devant de la scène en 1995, Microsoft a su rapidement adapter au Web cette métaphore qui guide ses développements graphiques depuis une dizaine d'années. Dans Internet Explorer, la page Web n'est finalement qu'une variété supplémentaire de conteneur COM. Les composants constitutifs du document sont alors appelés des contrôles ActiveX.

La généralisation du langage HTML (Hypertext Markup Language) et du Web ouvre le troisième mouvement de diffusion de l'idée du document comme conteneur. Ici le document (la page Web) contient des objets qui sont délimités par des balises dans le flux de texte. Les balises HTML sont utilisées aussi bien pour l'indication d'une mise en page ou d'un rendu particulier des données qu'elles délimitent que pour marquer des régions source ou destination de liens, dits hypertexte, entre pages. Un document Web ne contient pas à proprement parler d'autres pages Web mais pointe vers celles-ci via les liens hypertextes. Les deux nouveautés apportées par le Web à l'idée du document comme conteneur sont, d'une part, l'insertion d'objets destinés au contenant pour la présentation du document directement dans son contenu et, d'autre part, la fragmentation du document en un graphe de pages Web liées entre elles par des liens hypertextes. Le secours du langage de programmation Java permet de reproduire dans l'architecture Web le modèle des composants exécutables du document comme conteneur, en utilisant des balises HTML pour délimiter l'appel à du code exécutable téléchargé (le bytecode).

Les évolutions séparées des architectures bureautique et client-serveur traditionnelles d'un côté et de la plate-forme Web de l'autre aboutissent, en fin de compte, à la mise en place d'une infrastructure généralisée de documents-conteneurs répartis et mobiles, qui traverse les frontières entre réseaux locaux et Internet. Cette infrastructure documentaire émergente devient aujourd'hui une véritable plate-forme de développement et de déploiement d'applications. L'infrastructure logique moderne des applications informatiques d'entreprise distingue les couches de présentation, de traitement, et d'accès aux données. Il s'agit d'une élaboration du modèle client-serveur qui se développe dans les années 80, aux cotés de l'architecture centralisée autour du mainframe, avec la généralisation des PC et des réseaux locaux. Dans ces modèles classiques, la structure des données, la structure des traitements et la structure de l'interface graphique s'influencent mutuellement mais restent implémentées par des moyens distincts. Les interactions sont déléguées à l'infrastructure (circulation d'événements ou de messages, requêtes SQL ou objet, remote procedure calls ou callbacks…) que l'on cache sous le terme générique de middleware. Mais dans l'architecture Web le langage HTML ne convient que pour la couche présentation : il est l'équivalent de l'interface graphique dans le modèle classique. Qu'en est-il de la structure des données, de celle des traitements et des interactions avec le Web, nouveau middleware ?

La profondeur de la réponse à ces questions, voilà l'enjeu des débats autour de XML. Les pages Web contiennent des balises HTML qui sont autant d'informations sur la mise en page et la présentation du document par lui-même sans contenu particulièrement structuré. L'idée de balises immergées dans le flux continu d'un document n'est pas nouvelle. Ces langages sont apparus au début des années 60 et s'établirent lentement jusqu'à la ratification par l'ISO de SGML (Standard Generalized Markup Language) en 1986. La puissance expressive de SGML est en fait son principal handicap. Trop lourd et trop difficile à implémenter, SGML n'est pas parvenu à s'imposer dans le développement d'applications d'entreprise. La recherche de la simplification de SGML coïncide parfaitement avec le besoin d'extension et d'enrichissement de HTML ; le W3C s'empare du problème en 1996 et aboutit à la recommandation XML 1.0 en février 1998.

XML : structure logique et physique des documents

Un document XML contient des instructions, appelées balises, qui délimitent un objet identifiable. Au delà des simples instructions de présentation et de mise en page du document, les balises XML portent des informations supplémentaires qui sont interprétées par l'application recevant le document. L'exemple suivant pourrait être tiré d'un manuel technique :

<avertissement>
<parametre>Cette substance est inflammable</parametre>
<image source="../gif/inflam.gif"> Figure 1</image>
</avertissement>

Les balises sont indiquées par les caractères < et >, le caractère / annonçant la balise de fin. Les balises possèdent éventuellement des attributs qui précisent leur signification. Dans l'exemple précédent, source est un attribut de la balise image dont la valeur est ici le nom d'un fichier. Les racines historiques de XML sont évidemment dans le secteur de la publication des documents. Mais XML est tout a fait adapté à l'identification de structures de données complexes qui ne sont pas destinées à être imprimées ou même rendues visibles :

<transaction>
<time date="19980214"/>
<amount>650.25</amount>
<from id="HDN145">W. Gates</from>
<to id="JMC007">J.-M. Chauvet</to>
</transaction>

Le standard SMIL (Synchronized Multimedia Integration Language) du W3C met en oeuvre XML exactement de cette manière pour identifier les différents fragments (vidéo, son, image, texte) qui constituent une présentation multimedia.

Un document XML se caractérise par une structure logique et une structure physique. La structure logique du document le divise en unités et sous-unités pertinentes : ces unités sont appelées elements dans XML. La structure physique du document permet à ses différents constituants, appelés entities dans XML, d'être nommés et stockés indépendamment dans différents fichiers - ce qui favorise la réutilisation. Les données non XML, comme les images, sont incluses par référence. Par exemple, chaque chapitre d'un livre peut être représenté par un element contenant d'autres elements pour chacun des paragraphes, tables ou images qu'il renferme ; chacune de ces tables ou de ces images peut être stockée dans un fichier distinct d'entity, réutilisable dans le même document ou dans d'autres.

Dans un interpréteur XML, le pré-traitement consiste à rassembler et combiner les entities dans un flux unique ensuite validé par l'interpréteur à proprement parler. XML est en fait un meta-langage : il sert à décrire d'autres langages spécialisés dans tel ou tel secteur d'application ou bien, comme nous allons le voir, dans tel ou tel service ou opération dans l'architecture informatique.

Si XML s'attaque à la structure logique des documents, une spécification complémentaire (actuellement en cours d'adoption au W3C) précise comment des liens hypertextes les relient entre eux. Un lien hypertexte permet de relier une source à une ou plusieurs destinations dans le même document ou dans un autre. La source est appelée linking element et la destination une resource. La seconde partie de la spécification XML (Extensible Markup Language: Part 2. Linking), connue sous l'abréviation usuelle XLL, est beaucoup plus riche que SGML ou HTML.

La première définition de XLL concerne des liens dits simples à l'intérieur d'un document ou entre documents. La description de la cible est une URL (Uniform resource Locator), comme dans le langage HTML, suivi de l'identité de l'élément visé comme dans l'exemple suivant : cf. Introduction.

Plus généralement, XLL permet de pointer vers une ressource qui n'a pas d'identifiant connu à l'avance par le rédacteur du document. Grâce à des mots clefs particuliers on peut ainsi identifier, par exemple, le troisième chapitre, le deuxième élément dans le troisième chapitre, le cinquième paragraphe du quatrième chapitre, l'avant-dernier item de la liste du troisième chapitre, la seconde liste possédant l'attribut Type, etc. XLL spécifie de plus qu'un lien peut être immédiatement activé ou activé à la demande de l'utilisateur. Une fois cette activation provoquée, la ressource peut soit remplacer le document courant, soit être affichée dans une nouvelle fenêtre, soit encore être insérée à la place de la source.

La seconde définition de XLL concerne des liens dits étendus. Dans ce dernier cas, il y a plusieurs cibles au lieu d'une. Chacune des cibles est identifiée par un locator ou clef qui lui est uniquement associée. L'exemple suivant illustre les liens étendus :

…dont la création remonte à <extend>Napoléon
<locate href="…">Biographie</locator>
<locate href="…">Campagnes</locator>
<locate href="…">Le Premier consul</locator>
<locate href="…">Saint-Hélène</locator>
</extend>

Les liens simples comme les liens étendus peuvent porter un titre qui est un attribut particulier qui leur est réservé. Les locators peuvent porter un titre et un rôle permettant éventuellement à un interpréteur XML de les classer d'après leur usage.

Sans rentrer plus avant dans la description syntaxique des différents attributs des liens définis par la spécification XLL, il devrait ressortir de ce survol rapide la très grande souplesse voulue par les concepteurs de la norme. Les relations entre documents (ou à l'intérieur d'un même document) y sont envisagées dans leur plus grande généralité, élargissant encore les champs d'application et les modes de navigation dans de grands ensembles de documents.

XSL est une proposition de standard pour la description de l'apparence d'un document XML lors de sa publication (sur écran ou sur papier). Les définitions et les propositions contenues dans la spécification XSL visent l'interface graphique et le rendu du document XML du point de vue des lecteurs. Une règle de style associe un style (défini comme la combinaison d'une police de caractères et de ses attributs de taille, de couleur, de position…) à un élément particulier. Un document XSL, également appelé une feuille de style, contient un ensemble de règles de styles applicables à un ou plusieurs documents XML. L'avantage de cette distinction entre contenu (XML) et apparence (XSL) est double : le partage d'une même feuille de styles par plusieurs documents XML assure une présentation cohérente de l'ensemble (la feuille de style est alors souvent associée à une DTD qui définit les éléments de ces documents) ; le remplacement d'une feuille de style par une autre permet de modifier ou d'adapter la présentation d'un document sans retoucher son contenu.

Dans HTML les feuilles de style sont inutiles dans la mesure où le navigateur lui-même se charge de représenter le jeu de balises HTML suivant un code graphique prédéfini et fixe. Un standard de feuilles de style a néanmoins été défini en 1996 pour les navigateurs HTML sous le nom de CSS (Cascading Style Sheets). Utilisé pour appliquer un style donné à des éléments autres que les balises HTML, sa spécification n'en reste pas moins plus faible que XSL malgré quelques innovations récentes. À l'autre extrême, on trouve DSSSL (Document Style Semantics and Specification Language) co-développé avec SGML et livré comme standard ISO en 1996. La grande complexité de DSSSL le fait plutôt rare dans les produits commerciaux. XSL, compromis entre DSSSL et CSS, hérite certaines de ses caractéristiques de l'un et de l'autre.

La richesse d'expression des règles de style est source de conflits potentiels. Plusieurs règles peuvent en effet s'appliquer au même élément avec des résultats éventuellement contradictoires. XSL précise alors une préférence dans le choix des règles (la plus spécifique au détriment de la plus générale) ou bien un mécanisme de fusion des règles avant l'application de la combinaison des styles qu'elles associent à un élément. En désespoir de cause, une règle de style peut également porter une priorité permettant le classement numérique des règles de style en cas de conflit insoluble par ailleurs.

La présentation du document suivant les styles XSL se fait dans une juxtaposition de rectangles placés suivant une direction donnée (en général de haut en bas) et dont le contenu suit un mode donné d'écriture (de gauche à droite pour les langues occidentales). Ces rectangles définissent la surface du document, la surface des éléments qui le constituent (textes, graphiques, tables, séquences, lignes et autres) jusqu'à la surface des caractères dans le texte, celle des ligatures, etc. Une règle de style peut ainsi contrôler jusqu'au dernier pixel de l'apparence d'un texte ou d'une image dans le plus grand luxe de détails. Dans la définition des styles à appliquer à un élément donné, les valeurs des attributs peuvent être remplacés par des scripts. Ces scripts sont écrits dans le langage ECMAScript, résultat de la standardisation par l'ECMA (European Computer Manufatures Association) du langage de script JavaScript initialement créé par Netscape Communications. Ce niveau supplémentaire de flexibilité permet de créer de nouveaux styles au vol, au moment de la publication du document.

Enfin, XSL autorise un certain nombre de manipulations destinées à simplifier l'écriture et la compréhension des feuilles de style : réordonnancement des éléments d'un document (pour le style de tables de matières, d'index ou de glossaires, par exemple), macros pour factoriser la définition d'actions à effectuer dans les règles de style, référencement de styles par nom, etc. Le standard XSL assure une compatibilité avec HTML en définissant des objets standards correspondant aux balises HTML et utilisables dans les règles de style.

L'accès aux données en XML

XML plonge ses racines dans les standards SGML et HTML dont il reprend certaines des caractéristiques (mais pas toutes) avec l'objectif de devenir la plate-forme de référence pour les auteurs et les lecteurs d'ensembles de documents structurés. Les grands acteurs informatiques ont pratiquement tous déjà annoncés la livraison dans un futur proche de produits XML destinés à la circulation et la publication de documents électroniques.

La richesse de XML, à laquelle le survol de la section précédente ne rend pas complètement justice, repose sur la liberté de définition des balises qu'offre la spécification. Ainsi, il est possible d'associer une structure de document à un usage particulier de celui-ci. Si les premières applications envisagées visaient l'échange de documents informatiques (EDI), c'est-à-dire des usages spécifiques à un métier ou un secteur industriel donné, les premières implémentations de XML réalisées par des éditeurs et des acteurs du secteur informatique ont également généré un certain nombre d'applications nouvelles de la norme. La neutralité du langage XML, sa flexibilité et son adaptation parfaite à un environnement Web sont autant de caractéristiques intéressantes pour la représentation et l'accès aux données.

Cette section présente les premières tentatives d'utilisation de XML pour représenter, échanger et accéder aux données depuis ou entre applications réparties.

Meta Content Framework

MCF (Meta Content FrameWork) est un modèle de données initialement proposé par Netscape Communications. Chaque information est appelée un objet dans la spécification MCF. À un objet sont associées des propriétés, dont la définition met en jeu un type de propriété. Ces définitions sont sans surprise pour les habitués de la programmation ou de la conception orientée objet. MCF ne fait ici que reprendre le concept de description externe que l'on retrouve dans l'IDL (Interface Definition Language) de Corba ou dans celui de Microsoft. Les objectifs sont différents : alors que les définitions en IDL sont destinées à être traduites dans un langage de programmation pour construire des implémentations exécutables des objets en question, celles de MCF n'ont qu'un rôle descriptif qui peut être mis en jeu par des applications différentes. MCF utilise XML pour représenter les objets et des éléments XML inclus dans les précédents pour décrire les propriétés. L'exemple suivant illustre une construction MCF en XML :

<maison>
<occupant>Pierre</occupant>
</maison>

La propriété occupant est associée à l'objet maison et la valeur de celle-ci pour cette instance particulière est Pierre. Dans MCF, le type d'une propriété peut être lui-même un objet. Les objets peuvent donc être mis en relation via leurs propriétés comme dans l'exemple suivant :

<personne>
<age>35</age>
<taille>180</taille>
<habitation id="1310 Villa Street">
</personne>

<appartement id="1310 Villa Street">
<occupant id="Pierre"/>
</appartement>

Dans cet exemple, l'expression de la relation entre les deux objets personne et appartement passe par une propriété particulière, id, dont le rôle est identique à celui d'un index dans une base de données relationnelle. Un ensemble de données MCF s'apparente donc à un graphe dirigé dont les sommets sont les objets et les arêtes les propriétés qui pointent sur ces objets MCF.

XML-Data de Microsoft

Avec XML-Data, Microsoft propose un langage de description de données très puissant, compatible avec son propre format CDF (Channel Definition Format) pour la circulation de documents électroniques. La définition d'un schéma XML-Data est elle-même définie en XML à l'aide d'un DTD. Cette approche offre un double avantage : les schémas sont produits à l'aide d'éditeurs XML ou SGML standards qui peuvent en assurer la complétude et la conformité (limitant ainsi le nombre d'erreurs) ; de plus, le même interpréteur peut être utilisé par l'application pour lire les schémas et les données.

Notons d'une part que la puissance d'expression de XML-Data est supérieure à celle de MCF et, d'autre part, que tous les constituants d'un DTD peuvent eux-mêmes être décrits à l'aide de XML-Data. Voyons l'exemple suivant :

<!ELEMENT Maison ((isolee|appartement|terrasse), garage?)>

<elementType id="Maison"
  <group groupType="SEQ" occurs="REQUIRED">
    <group groupType="OR" occurs="REQUIRED">
    <elt href="#isolee"/>
    <elt href="#appartment"/>
    <elt href="#terrasse"/>
    </group>
    <elt occurs="OPTIONAL" href="#garage"/>
  </group>
</elementType>

La première définition, extraite d'un DTD, est équivalente à celle qui suit, exprimée en XML-Data. Du coup, on peut parfaitement imaginer de se passer complètement de la syntaxe particulière du DTD et la remplacer par l'utilisation conjointe de XML et des schémas en XML-Data.

Resource Description Framework

Devant les différentes initiatives des acteurs commerciaux et les risques d'incompatibilité et de fragmentation des marchés qu'elles représentent potentiellement, le W3C s'attaque à son tour au problème. Le RDF (Resource Description Framework) reprend l'idée des graphes dirigés : les sommets sont des ressources (objets ou valeurs de propriétés) et les arêtes sont les propriétés elles-mêmes. Ces graphes sont représentés par des énoncés, des triplets { ressource, propriété, valeur }. De plus, dans RDF, un énoncé peut lui-même servir de valeur dans un autre énoncé. Ainsi des relations arbitrairement compliquées entre données peuvent être, en quelque sorte, linéarisées (serialized) dans un document XML transmissible sur le Web.

XML-QL

Soumis au W3C en juillet 1998, XML-QL (XML Query Language) se donne pour but de répondre aux questions suivantes :

• Comment extraire les données de documents XML ? Comment faire quand les volumes de données et de documents sont importants ?
• Comment intégrer des données issues de documents XML distincts ?
• Comment convertir un DTD dans un autre ? Comment réconcilier des schémas de données différents ?

Illustrons la syntaxe XML-QL sur un exemple de requête. Soit un document XML faisant référence au DTD suivant :

<!ELEMENT book (author+, title, publisher)>
<!ATTLIST book year CDATA>
<!ELEMENT article (author+, title, year?, 
				(shortversion|longversion))>
<!ATTLIST article type CDATA>
<!ELEMENT publisher (name, address)>
<!ELEMENT author (firstname?, lastname)>

Cet exemple fictif décrit la structure de références bibliographiques, livres ou articles, et des informations qui y sont usuellement attachées. Une requête XML-QL sur un document XML conforme au DTD précédent prend la forme suivante :

WHERE <book>
        <publisher>
            <name>Hermes</name>
        </publisher>
        <title> $t</title>
        <author> $a</author>
      </book> IN "www.a.b.c/bib.xml"
CONSTRUCT <result> 
	<author> $a</author> 
	<title> $t</title> 
	</result>

La clause, annoncée par le mot-clé WHERE-IN, décrit la sélection visée par la requête, ici toutes les publications de l'éditeur Hermes. Les actions, annoncées par le mot-clé CONSTRUCT, s'appliquent à la sélection satisfaisant les conditions précédentes. Cette dernière clause construit en fait un fragment de document XML, balisé par <result>, dont la série constitue le résultat de la requête, lui-même un document XML. La phase de construction du résultat de la requête emploie des variables dont les valeurs sont assignées à la phase de sélection : c'est le rôle des variables $t et $a dans l'exemple. Un requête XML-QL transforme donc un document XML en un autre en extrayant et réorganisant les éléments qu'il contient.

De la même manière, il est alors possible d'utiliser XML-QL pour traduire d'un DTD dans un autre ou pour intégrer des documents conformes à des DTD distincts. Supposons que nous souhaitions transformer un document conforme au DTD que nous venons de voir en un document XML conforme au suivant :

<!ELEMENT person (lastname, firstname, address?, phone?, publicationtitle*)>

L'utilisation de la clause CONSTRUCT permet de transformer les éléments issus du premier DTD en éléments conformes au second.

WHERE <$> <author> <firstname> $fn </>
              <lastname> $ln </> </>
          <title> $t </> 
      </> IN "www.a.b.c/bib.xml",
CONSTRUCT <person ID=PersonID($fn, $ln)> 
              <firstname> $fn </> 
              <lastname> $ln </> 
              <publicationtitle> $t </> </>

Dans cet exemple, nous utilisons une notation abrégée (</>), autorisée par XML, pour fermer la dernière balise ouverte dans le flux de texte. De plus, ce fragment en XML-QL montre comment faire appel à des routines ou des programmes externes à l'interpréteur XML (PersonID) pour des calculs ou des opérations particulières. Ici cette opération crée un identifiant unique au document résultant de la requête qui individualise chacun des éléments (person) qu'elle construit.

L'homogénéité de la plate-forme de définition et de manipulation des données est la caractéristique majeure de l'apport de XML aux problèmes de représentation et d'échange de données. Les données du Web et celles des entreprises, collectées et préservées dans des systèmes de gestion hiérarchiques, relationnels ou navigationnels sont par définition hétérogènes et difficilement réconciliables. C'est là tout l'enjeu des entrepôts de données, soubassement de toutes les applications d'aide à la décision. XML, qui permet d'unir les architectures client-serveur traditionnelles de l'entreprise et la nouvelle architecture Web, promet de jouer un rôle essentiel dans la nouvelle génération de référentiels et d'applications à base de données.

Traitements et XML

Un échelon supplémentaire dans l'échelle des usages techniques de XML est franchi par les développements cherchant à utiliser XML pour représenter et manipuler les traitements eux-mêmes. Le but est ici d'employer XML comme langage de description des traitements aussi bien que de représentation des données. Pour comprendre comment XML et traitements interagissent, il convient de s'arrêter sur le fonctionnement d'un interpréteur XML avant de décrire les différentes approches en cours de développement.

Les interpréteurs XML

Les interpréteurs XML se divisent en deux catégories qui reflètent des choix techniques d'implémentation différents. Dans les interpréteurs pilotés par les événements, chaque ouverture et chaque fermeture de balise dans le document XML provoque l'émission d'un événement auquel est associé une fonction (en C ou en Java) appelé un call-back. Dans la seconde catégorie, les interpréteurs construisent en mémoire la totalité de la structure arborescente du contenu du document XML. Cette structure est ensuite manipulée par l'interpréteur en fonction de l'application qui le met en œuvre. Ce dernier fonctionnement s'apparente à celui d'un compilateur moderne dans lequel on sépare un front-end d'un back-end générateur du code exécutable.

Dans le premier cas, seule la structure locale du document XML en cours d'interprétation est présente en mémoire. Les interpréteurs qui suivent cette implémentation sont en général moins consommateurs en ressources mémoire que ceux de la seconde catégorie. En revanche, les traitements correspondants ne peuvent être que locaux puisque pilotés par le flux des balises, ouvertes et fermées, dans le document XML. Il existe aujourd'hui une API (Application Programming Interface) pratiquement standard pour les interpréteurs piloté par les événements en Java, appelée SAX (Simple API for XML).

Dans le second cas, c'est toute la structure du document qui est d'abord construite puis traitée par l'intepréteur. Dans ce cas également, il existe un début de standardisation de cette structure en mémoire et de l'API qui permet de la manipuler, appelé DOM (Document Object Model).

Le Document Object Model

DOM est un standard W3C spécifiant la structure et l'API orientée objet correspondante du contenu XML d'un document. DOM permet de manipuler par programme les différents constituants des documents XML. En particulier, DOM est conçu pour créer de nouveaux éléments, pour modifier ou pour détruire des éléments existants dans un document XML. DOM permet également de naviguer de manière programmatique dans un ensemble de documents XML liés entre eux. Enfin, l'API de DOM a été spécifiée en pensant également aux documents HTML traditionnels du Web auxquels elle s'applique aussi.

Pour assurer autant que possible l'indépendance de DOM vis-à-vis des langages de programmation, la spécification est écrite en IDL, le langage neutre de description d'interfaces de la norme Corba à laquelle DOM fait explicitement référence. L'utilisation des outils Corba du marché permet ensuite de transformer ces spécifications en codes source directement utilisables dans le développement d'applications XML. La spécification décrit également comment utiliser le langage standard de script ECMAScript avec les objets et les interfaces DOM.

Les futures livraisons de la spécification promettent de s'attaquer à une API pour XSL, les feuilles de styles associées aux documents XML, de prendre en compte le multitâche éventuel des applications qui utilisent les objets et les interfaces DOM, les contraintes particulières de sécurité, etc.

Le niveau actuel de la spécification de DOM, appelé Level One s'articule en deux chapitres. Le premier, Core, présente les objets et les interfaces couvrant le champ des documents XML ; le second, HTML, est consacré aux documents HTML et spécialise pour cet usage les interfaces et les objets du premier chapitre (par héritage).

DOM représente un document XML par une hiérarchie d'objets en mémoire (des objets C++, Java ou autres suivant le langage de programmation choisi). Le plus général de ces objets est décrit par l'interface DocumentFragment dont les descendants représentent les sous-arbres qui constituent le document XML.

L'interface Document décrit un de ces sous-arbres :

interface Document : DocumentFragment {
  readonly attribute DocumentType doctype;
  readonly attribute DOMImplementation implementation;
  readonly attribute  Element documentElement;
  Element createElement(in wstring tagName);
  DocumentFragment createDocumentFragment();
  Text createTextNode(in wstring data);
  Comment createComment(in wstring data);
  CDATASection createCDATASection(in wstring data);
  ProcessingInstruction createProcessingInstruction(in wstring target, in wstring data);
  Attribute createAttribute(in wstring name);
  Entity createEntity();
  EntityReference createEntityReference();
  NodeList getElementsByTagName(in wstring tagname);
};

Le modèle général de cette interface se retrouve dans pratiquement toutes les interfaces décrites dans Core. On y trouve les opérations de création et de destruction des structures (ici un arbre entier) qui représentent le contenu des documents XML.

Le niveau inférieur des nœuds dans l'arbre est décrit par l'interface Node, dans laquelle on retrouve les différentes natures d'éléments XML :

interface Node {
  // NodeType
  const unsigned short      DOCUMENT           = 1;
  const unsigned short      ELEMENT            = 2;
  const unsigned short      ATTRIBUTE          = 3;
  const unsigned short      PROCESSING_INSTRUCTION = 4;
  const unsigned short      COMMENT            = 5;
  const unsigned short      TEXT               = 6;
  const unsigned short      CDATA_SECTION      = 7;
  const unsigned short      DOCUMENT_FRAGMENT  = 8;
  const unsigned short      ENTITY             = 9;
  const unsigned short      ENTITY_REFERENCE   = 10;
  const unsigned short      DOCUMENT_TYPE      = 11;
readonly attribute  wstring              nodeName;
           attribute  wstring              nodeValue;
  readonly attribute  unsigned short       nodeType;
  readonly attribute  Node                 parentNode;
  readonly attribute  NodeList             childNodes;
  readonly attribute  Node                 firstChild;
  readonly attribute  Node                 lastChild;
  readonly attribute  Node              previousSibling;
  readonly attribute  Node                 nextSibling;
  readonly attribute  NamedNodeMap         attributes;
  Node    insertBefore(in Node newChild, in Node refChild)
raises(DOMException);
  Node    replaceChild(in Node newChild, in Node oldChild)
raises(DOMException);
  Node    removeChild(in Node oldChild)
raises(DOMException);
  Node    appendChild(in Node newChild);
  boolean hasChildNodes();
  Node    cloneNode(in boolean deep);
  boolean equals(in Node arg, in boolean deep);
};

Sans rentrer dans le détail des différentes opérations décrites par l'interface précédente, il suffit de noter que DOM définit d'abord la nature des éléments XML que ces objets programmatiques représentent (les déclarations const du début). L'interface définit ensuite la série des opérations nécessaires à la création, la destruction ou la modification de ces éléments d'un document XML. L'API permet aussi de naviguer d'un élément à l'autre du document XML, en parcourant la structure suivant différentes voies (par type, par relation d'emboîtement…). Pour faciliter encore cette navigation il est possible de nommer des éléments particuliers qu'on recherche ensuite par nom directement grâce à une API DOM spécialisée.

L'interface Node est ensuite spécialisée (par héritage) pour chacun des types d'éléments d'un document XML (element, property, processing instruction…). Level One Core décrit donc une interface orientée objet complète permettant à une application de travailler directement sur une hiérarchie d'objets en mémoire identique à la structure hiérarchique du document XML. DOM constitue donc le cœur des applications fondées sur XML.

Le second chapitre de DOM, Level One HTML, reprend les interfaces et les objets du premier chapitre, Core, et les spécialise pour la description des balises du langage HTML utilisé pour la rédaction des pages Web.

La spécification présente essentiellement une interface HTMLDocument qui hérite de Document et représente une page Web, ainsi qu'une interface HTMLNode qui hérite de Node pour les balises propres à HTML. Cette partie de DOM est destinée aux éditeurs de navigateurs Web qui souhaitent enrichir la représentation des pages Web et préparer leurs produits commerciaux à la présentation de pages en XML.

Parmi les produits commerciaux, beaucoup d'environnements de développement ont déjà fait le choix d'utiliser le langage XML pour décrire le référentiel de données ou de traitements nécessaire à la construction d'applications d'entreprise. XML est également utilisé comme outil d'assemblage de composants logiciels. En effet, XML permet de décrire la fonctionnalité d'un composant logiciel dans un format neutre, transmissible sur le Web et facile à exploiter moyennant des standards comme DOM.

En dehors du support (prudent) de XML annoncé par Sun au premier trimestre 1999, certains environnements de développement s'appuyant sur des serveurs d'applications mettent en avant un ensemble de documents XML comme référentiel pour les applications qu'ils permettent de bâtir :

• Allaire, SilverStream ou WebLogic (absorbé par BEA fin 1998) fournissent des serveurs d'applications dans lesquels XML joue le rôle de langage de description d'applications ;
• Neuron Data/Blaze Software offre un serveur de règles métier dans lequel ces dernières sont décrites dans des documents XML ;
• Vignette s'appuie sur XML pour associer des informations opérationnelles à un site Web pour permettre l'adaptation au vol de son apparence aux besoins de son visiteur.

Ces éditeurs, dont la liste est loin d'être exhaustive, sont accompagnés par Microsoft qui promet d'utiliser XML comme format de stockage de tous les documents produits par la suite Office 2000. Ils peuvent être considérés comme l'avant-garde d'un mouvement important qui devrait voir la banalisation de XML dans les ateliers de génie logiciel et dans les environnements généralistes de développement d'applications.

L'OMG, de son côté, est en train d'examiner la soumission XML Metadata Interchange, ou XMI, en réponse à un appel à proposition pour une normalisation des échanges de données entre référentiels d'applications, SMIF (Stream-based Model Interchange Format). Cette spécification propose l'adoption d'XML comme langage de description et d'échange de modèle de données entre applications ou entre référentiels d'applications. Les modèles UML (Unified Modeling Language), les schémas de données dans les gestionnaires de bases de données relationnelles ou encore les modèle des entrepôts de données sont tous des exemples de modèles de données au sens de l'OMG. Ces modèles sont souvent représentés et stockés dans des formats propriétaires qui dépendent des outils de conception ou des environnements de développement. La spécification XMI précise comment écrire ces modèles en XML, indépendamment de leur source ou des outils logiciels qui ont servi à les élaborer. XMI n'est rien d'autre qu'un format de transport neutre entre référentiels d'applications.

XMI fournit une série de DTD pour l'expression en XML des méta-modèles de données. Ces DTD permettent la validation des documents XML décrivant, quant à eux, les modèles de données. Comme dans les cas précédents ces phases de validation sont essentielles dans l'échange de description de structures de données qui peuvent être complexes (comme dans le cas d'un entrepôt de données, par exemple). Elles permettent de déléguer à l'interpréteur XML les tâches de vérification, de validation et d'intégration de modèles de données d'origines différentes, opérations qui nécessiteraient sinon d'alourdir l'importation ou l'exportation des modèles dans les référentiels eux-mêmes.

Poursuivant son oeuvre fédératrice, l'OMG avance donc avec XMI, qui a l'appui d'IBM, d'Oracle, d'Unisys, de Fujitsu, de Platinum (maintenant fusionné avec Computer Associates), de Softeam, de CRC/DSTC, de Recerca Informatica et de Daimle-Benz, une pièce importante dans la construction d'une architecture de développement et de déploiement d'applications à base d'objets répartis.

D'autres usages de XML associés à des traitements, plutôt qu'à des données, se répandent aujourd'hui sans attendre la disponibilité commerciale de produits complets. Similaire à l'idée des requêtes dans XML-QL, codées en XML et dont le résultat est lui-même un document XML, l'idée directrice de XML-RPC est d'implémenter un RPC (Remote Procedure Call) complet - un dispositif de communication par appel de procédure distant entre applications réparties sur un réseau - entièrement en XML.

Dans cet appel de procédure sur Internet, la requête et le résultat de son exécution sont des documents XML qui circulent donc directement sur le Web. Une requête doit préciser le nom de l'opération appelée, les arguments et leurs valeurs pour l'appel en question et, éventuellement, des informations contextuelles supplémentaires pour l'exécution de la procédure visée. Ces informations ne sont pas très différentes de celles qui constituent la signature d'une opération dans un fichier de déclaration en C, en C++ ou en IDL. On ne sera donc pas surpris de retrouver dans XML-RPC des " tournures de styles " que nous avons vu dans MCF, XML-Data ou RDF. L'exemple de requête XML-RPC suivant illustre ces similarités :

XMLTP (XML Transfer Protocol) est un protocole de transfert de fichiers ou de données, s'inspirant de FTP (File Transfer Protocol), dans lequel requêtes et résultats sont des documents codés en XML comme dans les exemples précédents.

AXTP est l'une des initiatives intéressantes autour de XML considéré comme support de plates-formes d'exécution de composants logiciels. AXTP est un protocole transactionnel léger, adapté au Web qui s'appuie d'une part sur Java Beans et d'autre part sur la couche de transport UDP.

Les transactions AXTP mettent en jeu trois éléments : un programme client, un service de transaction et un serveur. Une des originalités d'AXTP est de considérer d'emblée que la connexion entre le programme client et le service de transaction n'est pas fiable, ce qui est le cas d'applets dans une application Internet ou de clients mobiles comme des téléphones cellulaires par exemple. AXTP s'appuie, en particulier, sur des délais au-delà desquels le serveur est en droit d'abandonner la transaction si le programme client ne s'est pas manifesté. La connexion entre le service de transaction et le serveur est, par contre, considérée comme fiable. À un serveur est associé un service de transaction, ce qui simplifie la reprise après une défaillance. Les transactions AXTP peuvent être emboîtées et mettent alors en jeu plusieurs serveurs et différents services de transaction.

Le choix d'UDP, au détriment de TCP, conduit à une simplification de la gestion de la connexion entre le programme client et les serveurs. De plus, certaines restrictions de TCP dans les cas de communications par satellite, par téléphones cellulaires ou par systèmes à large bande passante sont éliminées.

Les responsabilités des différents éléments constitutifs du système transactionnel AXTP sont les suivants :

Le programme client doit conserver l'état de la transaction tant que celle-ci n'est pas terminée. Même si le programme client peut signaler la fin d'une transaction (validation ou annulation de la transaction en cours), il doit néanmoins attendre le message final du service de transaction (wipe ou quit) pour mettre effectivement fin à la transaction. En cas de défaillance du client, la récupération de l'état de la transaction immédiatement antérieur à la défaillance est à sa charge.

Le service de transaction conserve la trace de toutes les demandes d'exécution en cours. Les transactions deviennent inactives dès la réception du signal du client ou bien au bout d'un délai donné. Les transactions inactives sont définitivement effacées de la mémoire du service de transaction dès l'expiration d'un autre délai donné qui caractérise l'historique du service.

Le serveur exécute les demandes d'exécution envoyées par le client via le service de transaction auquel il est connecté. Chargé de veiller au bon déroulement de ces commandes, il conserve trace de l'état d'avancement des requêtes pour toutes les transactions actives du service de transaction.

AXTP repose sur des délais dont l'expiration déclenche automatiquement des changements d'état. C'est en cela qu'AXTP est plus léger que les moniteurs transactionnels classiques et s'adapte relativement bien aux situations d'instabilité des connexions entre clients et serveurs. Ces délais sont de trois types :

• T0 : le délai qui sépare deux tentatives réitérées d'émission de messages affiche une valeur initiale, puis se trouve incrémenté après chaque nouvelle tentative jusqu'à un maximum convenu d'avance ;
• T1 : temps maximal d'activité d'une transaction ;
• T2 : temps de conservation d'une transaction inactive dans l'historique du service de transaction.

Tous les messages qui circulent entre le programme client et le service de transaction sont formalisés en XML. Certains de ces messages requièrent des paramètres supplémentaires passés dans les balises XML. Les messages et leurs balises XML sont les suivants :

Certains de ces messages comportent des champs valués qui distinguent les transactions les unes des autres :

En une dizaine de messages distingués par leurs balises XML et quelques paramètres supplémentaires, AXTP formalise les phases essentielles d'une transaction entre un programme client et un serveur. XTP profite de la légèreté de l'infrastructure offerte par le Web et prend en compte des connexions instables entre clients (éventuellement mobiles) et serveurs (fixes).

Il existe une implémentation de démonstration et de test d'AXTP, écrite en Java et utilisant Java Beans. Si AXTP ne saurait concurrencer aujourd'hui les moniteurs transactionnels classiques ou les serveurs d'application à base d'objets, il d émontre néanmoins que XML permet de créer une architecture complète de traitement aussi bien que d'accès aux données.

L'initiative Coins complète ce tableau et vise à faire de XML le langage de description des composants logiciels. Nous avons remarqué à plusieurs reprises que les composants logiciels se distinguent du simple code exécutable par les d'informations supplémentaires qu'ils comportent, utiles aux phases d'analyse, de développement et de déploiement. Si toutes les architectures de plate-forme de développement et de déploiement de composants logiciels passées en revue ici font appel à une approche déclarative pour enrichir le code exécutable (bytecode ou code compilé), chacune repose sur des choix techniques propres, ce qui rend les plates-formes difficilement compatibles avec les autres. Dans les Java Beans, cette information est associée au bytecode dans la classe BeanInfo. Cette classe est générée automatiquement ou manuellement par le programmeur, et liée au bytecode dans les fichiers au format jar. L'information est complétée par les descripteurs de déploiement dans les Enterprise Java Beans pour les services supplémentaires de sécurité et de transaction. Dans le modèle DCOM/ActiveX de Microsoft, une bibliothèque de types est associée au composant DCOM. Ces associations sont centralisées dans le registre, clé de voûte de l'architecture Windows. MTS enrichit l'information sur les composants de propriétés liées aux services de transaction et de sécurité, également indépendantes du code proprement exécutable du composant DCOM. Par deux voies similaires on atteint au même but, mais les mécanismes imposés par ces différentes architectures sont spécifiques et reflètent le choix dichotomique fondamental entre Java et sa machine virtuelle et DCOM/ActiveX.

Coins propose de mettre à profit l'extensibilité de XML pour faire des documents XML le véritable référentiel des applications à base de composants. Aujourd'hui, tourné vers le monde Java, et vers Java Beans en particulier, car parfaitement adapté à la circulation de documents sur Internet ou sur les intranets, Coins pourrait de la même manière s'appliquer aux composants DCOM.

Dans Coins, XML est utilisé à la fois comme format de persistance des composants Beans, remplaçant la sauvegarde (serialization), et comme format de description des attributs de développement et de déploiement du composant logiciel. Ainsi associée au code exécutable qui peut être référencé dans le même document XML (à la façon d'une applet ou d'un composant ActiveX), l'information explicite transforme le document en véritable objet de calcul.

Si l'on compare la sauvegarde standard des composants Java Beans aux possibilités offertes par XML, force est de constater XML offre davantage de perspectives que le processus de sérialisation. D'une part, ce processus est complètement dépendant de la structure du bytecode Java et d'autre part on ne peut l'utiliser que pour reconstituer une image des classes Java conforme à l'original. En revanche, XML offre une riche structure de document, a priori indépendante de la structure du bytecode des classes Java qu'il décrit et dont l'interprétation est également indépendante des objets qu'il contient ; la représentation interne du résultat de l'interprétation d'un document XML est laissée au libre choix du programmeur, ce qui donne un degré de liberté supplémentaire. Enfin, XML offre plus de types de références que la seule référence à un objet persistant que l'on trouve dans la sérialisation Java.

Le document XML devient alors un véritable objet de calcul, un composant logiciel à part entière, regroupant le code exécutable et les informations nécessaires à l'assemblage de ce composant dans des applications. La plate-forme d'exécution n'est rien d'autre que l'infrastructure Web déjà en place, enrichie de services de développement et de déploiement de composants décrits aussi en XML.

Un document Coins contient le bytecode du composant Java Bean et la description de ses propriétés, de ses méthodes, de ses événements et de son état. Les spécifications de Coins indiquent comment passer du code source en Java au document XML correspondant et vice versa. Assembler des composants logiciels revient alors à lier entre eux des documents XML par des liens hypertexte. Cet usage peut également être combiné à celui de XML-Data dans le même document. Prises ensemble, ces variations d'interprétation du document XML promettent d'en faire une technologie de choix pour la description et l'assemblage d'applications réparties.

XML et les composants métier

XML, conçu initialement comme un langage de description de données destinées à la publication électronique sur le Web, est amené à jouer un rôle fondamental dans l'architecture des applications informatiques s'appuyant sur l'architecture Web. XML est de plus en plus souvent utilisé pour représenter des données (structurées et non structurées) et y accéder, et plus encore, pour décrire et exécuter à distance des traitements ou des opérations. L'une des déclinaisons naturelles de cette richesse expressive du langage et des usages innovants qu'il suscite se trouve alors dans son emploi dans des secteurs industriels spécifiques ou pour automatiser des classes de tâches spécialisées.

Si une première lecture de ces déclinaisons fait immédiatement penser à l'EDI (Electronic Document Interchange) et aux normes comme EDIFACT, par exemple, l'enjeu de ce type de protocole ou de format d'échange est plus grand que ceux attachés à ces techniques. Parce qu'il s'appuie sur la formidable plate-forme que représente le Web, dont l'universalité et la disponibilité croissante sont les atouts uniques du commerce électronique, et parce que, comme nous l'avons vu, XML permet également de s'attaquer à la représentation des traitements (et à l'échange de leurs descriptions), ces premières initiatives sont annonciatrices d'une généralisation de l'emploi du langage XML comme pivot des relations économiques fondées sur le Web.

OTP

OTP (Open Trading Protocol) est une soumission à l'IETF (Internet Engineering Task Force) qui met en jeu XML pour décrire un protocole, aussi indépendant que possible des systèmes propriétaires qu'il cherche à relier, standardisant les transactions de commerce électronique sur le Web. Soutenu par un consortium d'éditeurs de logiciels et de grands sites Web marchands, OTP classe les scénarios d'achat et précise la nature de l'information nécessaire à la bonne fin de ces transactions marchandes. Ces informations sont représentées dans des fichiers XML échangées par les différentes parties concernées dans chaque scénario envisagé.

L'objectif annoncé par l'organisation OTP est d'une part de favoriser les éditeurs de logiciels destinés au commerce électronique en proposant des protocoles d'achat et de vente standardisés et, d'autre part, de simplifier pour les utilisateurs l'exécution de transactions électroniques au travers d'interfaces et de modes opératoires cohérents d'un site Web à l'autre. Le protocole permet de répliquer dans le monde virtuelle les habitudes apprises dans le monde commercial " réel " et s'occupe de la facturation, des reçus, etc. Le protocole cache les différences parfois importantes entre les nombreux moyens de paiement employés sur le Web (SET, Mondex, Digicash, E-Check, Cybercoin…) sous une interface unique, facile d'emploi. OTP est également compatible avec les systèmes de gestion de programmes de fidélité, comme Netcentives, qui commencent à apparaître sur les sites marchands.

Les avantages attendus d'OTP, si son adoption se généralise, résultent de l'homogénéité et de la simplification des actes d'achat électronique qu'il promet d'apporter au monde virtuel. Les éditeurs de solutions Web comme les consommateurs ne peuvent que trouver leur avantage à une standardisation des échanges d'information. Bien sûr, comme dans toute initiative à visée généraliste, cette banalisation ne se fera pas sans surmonter d'obstacles, dont la résistance de certains acteurs financiers, pour qui les systèmes de paiement électronique propriétaires constituent encore un facteur de différenciation important dans la migration de leurs activités en ligne. OTP propose en effet de solutions concrètes pour la formalisation des échanges entre consommateurs, commerçants et banques qui couvrent tous les aspects d'une transaction marchande, depuis la demande d'offre initiale jusqu'aux accusés de réception des règlements et de la livraison de marchandise.

ICE

ICE (Information and Content Exchange) est peut-être aujourd'hui le plus abouti des protocoles métier fondé sur XML. Initialement proposé au W3C par Microsoft, Adobe, Cent, Sun et Vignette, ICE est une formalisation des échanges d'information pour la syndication et l'agrégation de contenus entre éditeurs et abonnés en général. ICE est en priorité destiné aux sociétés dites de new media, éditeurs et sources d'information financière, sportives, d'actualité ou autre qui utilisent le Web comme principal outil de diffusion. Les applications d'ICE peuvent néanmoins se décliner par secteur industriel et il est tout à fait envisageable, par exemple, d'employer ICE pour fédérer dans un extranet une entreprise et son réseau de fournisseurs, ou encore pour faciliter les échanges entre les différents acteurs d'une chaîne de valeur ajoutée (on pense à la logistique ou à la production).

Dans ICE l'information qui est publiée par un ou plusieurs éditeurs, qui sont alors syndiqués, est présentée dans des catalogues sous formes de paquets cohérents auxquels les consommateurs s'abonnent pour un prix donné. La première fonction remplie par ICE est l'identification et l'authentification de ces paquets d'information et de leurs abonnés. Cette identification permet évidemment la gestion de la facturation des abonnements mais aussi la répartition des revenus aux éditeurs syndiqués qui contribuent à sa publication et la gestion des versions et des mises à jour le cas échéant.

ICE offre des modes d'abonnement dits push - le paquet d'information est envoyé aux abonnés dès qu'il devient disponible ou à intervalles réguliers sur la base d'un accord préalable - et pull - le paquet d'information est envoyé à la demande des abonnés. ICE se charge des difficultés supplémentaires dues à la garantie de la sécurité des échanges et à l'internationalisation éventuelle des contenus ou de la base d'abonnés.

ICE dispose de plus d'un mécanisme original appelé les contraintes ICE qui permettent de définir les frontières du contenu d'un paquet d'information pour un abonné, ou pour une classe d'abonnés particuliers. Une contrainte ICE peut par exemple indiquer la taille maximale (en pixels) des bandeaux publicitaires associés à une information envoyée à un abonné donné. Toute l'information circulant au travers d'un serveur ICE est auditée et les traces de l'audit peuvent être consultées par les administrateurs du ou des sites marchands. Cet audit est le cœur de la répartition des flux d'information et des flux de revenus entre éditeurs et abonnés dans le modèle ICE. Toutes les données qui accompagnent l'information proprement dite publiée vers leurs abonnés par les éditeurs figurent dans un balisage XML de ces informations, elle-même sous forme multimedia compatible avec le protocole de transport du Web. En jouant ici son rôle initial de description et de classification d'information, XML dans cet emploi particulier dans un secteur défini met pleinement en valeur ses avantages que constituent sa richesse expressive et sa compatibilité avec les protocoles de communication du Web.

Conclusions

Au terme de ce parcours rapides des voies ouvertes par la standardisation et l'adoption progressive de XML par différents acteurs informatiques (programmeurs, éditeurs de logiciels et de progiciels, utilisateurs ou consortia industriels), il apparaît clairement que les enjeux de cette généralisation vont bien au-delà de la simple publication de documents électroniques.

XML, conçu pour expliciter et valider la structure des documents au fil même du contenu de ces documents par un balisage flexible et peu contraignant, s'est vite retrouvé employé comme langage neutre de représentation de données, de requêtes, de transactions, de référentiels, de traitements voire d'information propres à un métier ou à un mode opératoire régissant des échanges économiques. Son rôle croissant comme pivot de l'échange de données entre les applications initialement conçues avant la diffusion de l'accès au Web et les nouvelles applications mettant à profit cette nouvelle architecture Web promet d'accélérer son adoption et, en fait, son intégration dans la fabrique même du Web sous forme de protocoles spécialisés dont la complexité ou la spécificité, invisibles du point de vue de l'utilisateur, se chargeront des échanges de plus en plus diversifiés et raffinés qui prendront place sur le Web.