Rechercher :         

L'élaboration des standards XML prend les allures d'une histoire sans fin. Pourquoi semble-t-il nécessaire d'élaborer autant de dérivés de ce méta-langage ?
Michaël Tartar : Il faut bien distinguer deux types de standards : les fondamentaux de XML, qui constituent un socle technologique générique, et les dérivés métiers de XML.
Les premiers, élaborés par le World Wide Web Consortium (W3C), complètent le langage XML et dessinent peu à peu une sorte de langage de programmation capable de traiter tous types de documents structurés. Les seconds, soutenus par d'autres alliances qui réunissent souvent les acteurs d'un secteur industriel, s'apparentent à des applications verticales de XML. Ce second type de standard est indispensable: le champ d'action du W3C concerne seulement les fondations technologiques de XML; pour produire des applications métiers, d'autres consortiums doivent forcément prendre le relais. Et, c'est vrai, cette situation crée un peu de confusion. Dans un cas comme dans l'autre, il faut garder à l'esprit que ces travaux sont récents. XML n'est devenue une recommandation du W3C que le 10 février 1998. Certaines des briques fondamentales viennent tout juste d'accéder à ce statut, quant aux applications verticales nous n'en sommes qu'au début de l'histoire

Vous employez le terme de "recommandation", notion directement attachée au mode de fonctionnement du W3C. Pouvez-vous l'expliquez à nos lecteurs ?
L'étape de la "recommandation" c'est un peu celle de la normalisation: le moment où une spécification est validée par le consortium et rendue publique pour être accessible à tous. Tant qu'un langage ou un protocole n'a pas ce statut, aucun éditeur ne peut se targuer d'être en conformité avec un standard. Les utilisateurs doivent en être bien conscients: mettre en oeuvre une spécification qui n'est pas encore devenue une recommandation, c'est prendre le risque de devoir gérer ensuite des incompatibilités.

Dans ce contexte, comment faut-il comprendre le "support de XML" mentionné dans les caractéristiques des produits ?
En soi, quand un éditeur clame qu'il "supporte XML", cela ne veut strictement rien dire. En revanche, si un éditeur d'EAI précise que ses logiciels exploitent telle version de XSLT ou encore si un éditeur de logiciel de gestion électronique des achats annonce qu'il se conforme à CXML (C pour Commerce), alors ces informations de support deviennent pertinentes. Bref, pour comprendre le "support de XML" affiché par un éditeur, il faut décortiquer le contexte applicatif et la liste des dérivés de XML effectivement pris en compte.

Cette analyse demande un travail de veille colossal. Comment les utilisateurs aboutissent-ils à XML? Est-ce un pré-requis inscrit dans les appels d'offres ou bien est-ce vous qui préconisez ces standards ?
Aujourd'hui, XML est très clairement inscrit par les utilisateurs dans le cahier des charges des projets de gestion de contenu et d'intégration d'applications. Par souci bien sûr d'investir dans des architectures pérennes. Ensuite, lorsqu'il s'agit d'examiner en détail le choix des standards, les utilisateurs n'ont pas forcément le recul suffisant et en appellent donc à nos conseils.

Essayons toutefois de les guider un peu. Concernant les fondamentaux de XML, comment catégorisez-vous les différents langages proposés par le W3C ?
Disons qu'il faut d'abord distinguer les grands piliers de XML. Parmi eux, figure notamment XSLT, un langage destiné à transformer des documents via l'appplication de modèles. Sans surprise, XSLT est très utilisé dans le contexte de l'EAI. Autres piliers, XML Schema qui permet entre autres de typer des données par exemple pour fixer le format d'une date. XML Shema représente une pièce importante car XML étant issu de la gestion document il n'intégrait par défaut un typage complet des données. Enfin, je citerai aussi les "Namespaces" avec lesquels il est possible d'appliquer au sein d'un même document différents vocabulaire. De cette manière, une balise "<Name>" n'aura pas le même sens durant tout le document: dans un segment du document, la balise renverra à un nom de personne, et dans un autre elle qualifiera un nom de produit.

Outre ces piliers, quelles sont les autres pièces du puzzle XML ?
Il existe toute une famille de langages dévolus à la navigation au sein des documents XML: XPath, pour accéder à des parties de documents, XPointer qui va un cran plus loin encore dans la granularité, XLink qui permet de gérer des liens multi-cibles ou encore d'intégrer dans le document même le contenu ciblé, XML Query qui s'apparente à un SQL dédié à l'univers XML. On peut mentionner aussi XSL FO pour le formatage de documents paginés, utile par exemple pour générer du PDF (format Acrobat d'Adobe, ndlr) à partir d'un document XML, ou encore SVG pour la représentation de graphiques vectoriels 2D. Attention toutefois: dans cette liste, beaucoup de langages n'ont pas encore franchi le stade de la recommandation. Si XML Schema et XSLT ont bien été validés, ce n'est pas le cas en revanche de XML Query, de XSL FO ou de SVG, même s'il existe déjà un plugin signé Adobe pour ce dernier.

De la même manière peut-on catégoriser les applications verticales de XML ?
C'est forcément plus compliqué. Tout d'abord, ces langages-là n'étant pas suivis par le W3C, il n'y a pas à attendre de "recommandation". Il faut surveiller le nombre d'acteurs qui soutiennent effectivement ces initiatives. Un langage comme CXML, qui facilite entre autres la synchronisation de catalogues, paraît adossé à un nombre conséquents de grandes entreprises et pas seulement du domaine technologique. Il faut aussi examiner attentivement la couverture fonctionnelle de ces standards. Surtout quand ils fourmillent. Prenez le domaine de la banque et de la finance, il existe au moins une demi-douzaine de projets: FpML (Financial products Markup Language), XBRL (eXtensible Business Reporting Language), IRML (Investment Research Markup Language), RIXML (Research Information Exchange Markup Language), SWIFTML (SWIFT Markup Language). Les suivre demande un travail de veille à part entière.

Une consolidation s'impose, non ?
C'est une évidence. La maturation de XML passera forcément par une consolidation des vocabulaires métier. Mais pas seulement. Je crois qu'il faudrait aussi un support plus large des différents langages sur le poste client. Prenez l'exemple d'XLink: s'il était exploité dans un navigateur, il serait possible de constituer dynamiquement des documents par agrégation des contenus cibles des liens. L'information embarquerait plus d'intelligence, ce qui est bien l'objectif de XML.

Que manque-t-il encore à vos yeux pour que la révolution XML prenne toute son ampleur ?
Les outils de développement doivent davantage masquer la complexité. Travailler en s'appuyant sur la galaxie des langages XML demande encore trop souvent de mettre les mains dans le cambouis. Enfin, les formations initiales ne semblent pas avoir pris la mesure de l'enjeu. Je crois sincèrement que dans les programmes des écoles d'ingénieurs, l'apprentissage de XML doit devenir aussi naturel que celui de la structure des bases de données ou de SQL. Et manifestement, c'est encore loin d'être le cas.