« Cette application exporte en XML », « les données sont stockées dans un fichier XML », « pour ton programme, je te conseille d'utiliser XML ».Visiblement, XML est un bon Buzzword. Il sert d'argument commercial autant qu'il semble être la solution miracle dans des discussions de développeurs. Une solution miracle ? Voici un bon candidat au Graal. Examinons donc ce qu'est XML.

XML signifie eXtensible Markup Language. Ils'agit encore ici, après UML, d'un langage. Là s'arrête la comparaison, les buts et les moyens de ces deux langages n'ont strictement rien à voir ¹.

XML est un dérivé de SGML, tout comme le fameux HTML et pour cela, il a,lors de sa naissance, été souvent associé au Web, provoquant ainsi incompréhensions et confusions quant aux buts et aux applications de XML.

XML et HTML ont à eux deux donné naissance à XHTML, brouillant encore un peules pistes.

L'incompréhension donnant lieu à du rejet, nous avons notre part d'opposant àce langage. Les signes d'un faux Graal se dessinent. Ils se renforcent lorsque, XML devenant à la mode, les utilisations en deviennent abusives :comme indiqué en introduction, on met et on voit du XML partout. XML étant alors parfois employé dans des cas inappropriés, l'opposition se renforce.

Qu'est-ce donc qu'XML ?

À nouveau, un langage. Mais les interlocuteurs concernés par ce langage sont différents de ceux concernés par un langage de programmation (comme le C++) ou de modélisation (comme UML). XML est un langage qui s'adresse à un programme.Le locuteur, quant à lui, peut-être un humain ou un autre programme. En fait,tout est fait dans XML pour qu'il soit un langage de communication entre programmes tout en laissant la possibilité à l'humain de comprendre ce qui est transmis, y intervenir ou même écrire un message de toute pièce.

Une autre spécificité de XML est que c'est qu'il ne définit pas complètement la communication. Il définit une « orthographe » mais très rarement une sémantique sur les mots utilisés. XML défini aussi une structure et une grammaire, mais très peu de sémantique sur cette grammaire.

Ainsi, dans le fragment XML qui suit, la sémantique de « horaire », « départ »,ou « arrivée », n'est pas définie par XML. La seule chose que défini XML est que « départ », tout comme « arrivée » sont inclus dans « horaire ». La sémantique de l'inclusion, elle, est laissée aux interlocuteurs.

De même, « lieu » est défini comme étant un attribut, mais pas plus.

    <horaire>
        <depart lieu="Paris">18h30</depart>
        <arrivee lieu="Montpellier">12h30</arrivee>
    </horaire>

On constate deux choses à la lecture de ce fragment de XML : la lecture par un humain en est aisé, pourvu qu'il comprenne le français et la lecture (le parsing) par un programme l'est aussi car le XML est « bien formé » (une balise ouverte sera fermée et il n'y a pas chevauchement de balises).

À quoi XML sert-il ?

C'est la question qui a été posée dès l'arrivée de XML. Un fichier texte, ça n'impressionne pas beaucoup et il est très facile d'écrire sa propre structure pour son programme. C'est d'ailleurs ce qui était fait avant son arrivée. Etc'était d'ailleurs un soucis.

Une structure de données texte pour un programme, cela demande à être conçu, à écrire un parser (le bout de programme qui va lire les données) et des outils d'éditions.

XML allège le travail nécessaire : la base de la structure est là, des parser sont été écrits, des éditeurs plus ou moins spécialisés proposés, des outils de manière générale allant de la coloration syntaxique à l'aide à la conception.

Pour le développeur, il reste à donner du sens à la structure de son fichier(ce qui n'est pas rien), mais les tâches communes lui sont épargnées.

C'est ainsi qu'est né, naturellement, le XHTML : c'est une version qui utilise la sémantique des balises HTML tout en profitant de la structure du XML.

Un Graal ?

Après la découverte des possibilités de XML et de ce que cela apportait, ils'est mis à être présent partout. Même là où cela n'était pas nécessaire. Même là où il n'était pas à sa place.

Des données par milliers...

Comme XML structure des données et un langage de requêtes dans cette structure(XPath), il a été pris pour une base de données.XML n'est pas fait pour. Il est vrai qu'il est possible de faire de requêtes,mais XML est une donnée texte linéaire : difficile à mettre à jour et pas très efficace pour la recherche.

Il est par contre envisageable de sauvegarder une base de données en XML oud'utiliser une telle sauvegarde pour une importation. Il est aussi envisageable de s'en servir comme fichier de sauvegarde (l'équivalent d'une petite base de données). On peut aussi imaginer d'écrire des requêtes sur une base grâce à XML et d'en recevoir les résultats en XML.

Mais le stockage de données efficace, lui, est l'affaire des bases de données ².

Des micro données

À l'autre bout de l'échelle, XML s'est invité partout jusqu'à ce qui pourrait être considéré un usage surdimensionné. Lorsqu'un programme à besoin de lire un fichier de deux lignes, faut-il vraiment utiliser XML ?

Et s'il n'y a pas besoin d'une structure complexe, est-ce qu'un .ini ne serait pas suffisant ?

La réponse à ces interrogations n'est pas si simple. Des parsers de .INIexistent, et il ne sont pas difficiles à implémenter. Et si aucune structure n'est nécessaire, lire des lignes de textes est trivial. On peut donc penser qu'il ne faut pas s'embarquer dans une structure XML un peu plus lourde à gérer. On peut aussi penser que, comme souvent, les projets sont amenés à évoluer et que le petit fichier d'aujourd'hui sera peut-être plus gros demain.

Des données binaires

XML est un format textuel : il est formé de caractères alphanumériques dans un codage donné, par défaut UTF-8. Ce format n'est donc pas fait pour transporter des données binaires. Il est cependant possible de le faire, à la manière dont le binaire est transporté depuis longtemps dans les courriers électroniques :en utilisant un codage du binaire vers l'espace alphanumérique (avecuuencode ouBase64 par exemple).

L'inconvénient de ces codages est qu'ils multiplient la taille du fichier encodé. On est donc en droit de se demander si utiliser un encodage fait pour des transports via des media qui ne supportent que le texte dans un format accès sur le texte pour transporter des données binaires est un choix judicieux.

S'il est possible de transmettre ou de stocker des fichiers binaires, autant laisser des références dans le fichier XML vers ceux-ci.

Choix de structure

J'ai déjà eu l'occasion de voir des commentaires en défaveur de l'utilisation de XML sur la base de l'inadéquation avec le binaire. Ou bien parce qu'il est considéré trop verbeux.

Il s'agissait à chaque fois d'un incompréhension. Utiliser XML ne signifie pas« l'utiliser pour toutes les données » comme on vient de le voir précédemment.Cela ne signifie pas non plus que l'on doit être nécessairement tout décrire.

Un cas dont je me souviens était un refus d'utiliser XML pour coder une image car cela devrait forcément ressembler à cela (d'après l'auteur) :

    <pixels>
        <color red="244" green="10" blue="0" />
        <color red="234" green="0" blue="10" />
        <color red="204" green="0" blue="20" />
        ...
    </pixels>

Il s'agissait bien entendu d'une incompréhension de ce à quoi sert XML et d'une mauvaise modélisation du problème. Dans ce cas-ci, il fallait évidemment utiliser un format d'image référencé par le XML et non décrire chaque pixel.Même un codage texte intégré au XML plutôt qu'une référence aurait été plus simple et moins coûteux en place.

De même, s'il s'agissait de ne stocker qu'une palette de couleurs, il était aussi possible d'écrire <color>#F40A00</color> à la façon d'HTML, éventuellement en précisant quelque part dans la structure de données le format utilisé (RGB888 ici).

Pourquoi refuser d'utiliser en bloc XML quand il se comporte mal sur des cas pour lequel il n'est pas adapté ? C'est une bonne question.

Faux Graal

XML est passé par les phases classiques du faux Graal : son arrivée est sujette à des confusions, il est ensuite vu comme le moyen ultime de sauvegarde et transmissions de données puis finalement, il est compris et utilisé pour ce qu'il est : un moyen de sauvegarde et de transmission pour certaines données.