FlowingDev

XML, expliqué : le format de données en costard-cravate

XML (Extensible Markup Language) est un langage basé sur des règles pour encoder des documents dans un format qui est à la fois lisible par l'homme et par la machine.

Essayer l'outil: Visionneuse XML

En une phrase

XML est une manière ultra-stricte de structurer des données en utilisant des balises personnalisées, ce qui le rend lisible à la fois pour vous et pour votre ordinateur, mais surtout pour votre ordinateur.

Le problème qu'il résout

Aux premiers jours de l'informatique, partager des données entre différents programmes était un vrai cauchemar. Chaque entreprise avait son format de fichier à sa sauce secrète. Essayer d'ouvrir un document de WordPerfect dans Microsoft Word relevait de l'aventure. On appelait ça le vendor lock-in (ou dépendance vis-à-vis d'un fournisseur), et c'était un bazar sans nom.

Le boom de l'internet a rendu ce problème dix fois pire. Désormais, il ne s'agissait plus de deux programmes sur un seul ordinateur, mais de milliers de serveurs et de clients différents dans le monde entier qui devaient se parler.

La première tentative pour résoudre ce problème pour le web fut le HTML (HyperText Markup Language). Le HTML est génial pour dire à un navigateur comment afficher l'information : ceci est un titre (<h1>), ceci est un paragraphe (<p>), ceci est en gras (<b>). Mais il est nul pour décrire ce que l'information est. Ce texte en gras est-il un nom de produit, un avertissement, ou juste un truc que vous trouviez cool en gras ? L'ordinateur n'en a aucune idée.

C'est là qu'arrive XML (eXtensible Markup Language) à la fin des années 90. Il est issu d'un standard plus ancien et plus académique appelé SGML, mais a été simplifié pour une utilisation à l'échelle du web. La partie « eXtensible » est tout l'intérêt : contrairement à l'ensemble fixe de balises du HTML, XML vous permet d'inventer les vôtres.

Au lieu de <p>, vous pouvez créer <nom_produit>, <prix>, <adresse_livraison>, ou <coordonnees_du_repaire_secret_dans_le_volcan>.

Soudain, on avait un moyen d'échanger des données qui portaient leur propre signification. Les données étaient auto-descriptives. C'était révolutionnaire pour tout, des transactions B2B (business-to-business) aux fichiers de configuration d'applications. Ça a créé un langage universel que deux systèmes quelconques pouvaient convenir de parler, tant qu'ils suivaient les règles.

Comment ça marche sous le capot

XML ressemble à un tas de chevrons, mais sous cet extérieur épineux se cache un système puissant et logique. Il est construit sur quelques concepts fondamentaux.

L'anatomie de base : Balises, Éléments et Attributs

L'unité de base de XML est l'élément. Un élément se compose d'une balise de début, d'un contenu et d'une balise de fin.

<livre>Guerre et Paix</livre>
  • Balises : <livre> est la balise de début, et </livre> est la balise de fin. Notez le slash / dans la balise de fin. C'est obligatoire.
  • Contenu : Guerre et Paix est le contenu de l'élément. Le contenu peut être du simple texte, ou ça peut être... d'autres éléments ! C'est cet emboîtement (ou nesting) qui donne sa structure à XML.

Les éléments peuvent aussi avoir des attributs, qui sont des petites bribes de métadonnées qui vivent à l'intérieur de la balise de début.

<livre langue="fr">
  <titre>Guerre et Paix</titre>
  <auteur>Léon Tolstoï</auteur>
</livre>

Ici, langue="fr" est un attribut de l'élément livre. Il fournit des informations supplémentaires sur l'élément lui-même, plutôt que de faire partie de son contenu principal. Le choix d'utiliser un attribut plutôt qu'un élément enfant est un débat classique chez les développeurs, mais une bonne règle de base est : si ça décrit le contenu, c'est un élément ; si ça décrit le contenant, c'est un attribut.

La structure en arbre (DOM)

Quand un ordinateur analyse (ou parse) un fichier XML, il ne voit pas un mur de texte. Il voit un arbre. Cette structure logique est appelée le Document Object Model, ou DOM.

Voyez ça comme un arbre généalogique :

  • Il y a toujours un unique élément racine tout en haut (dans notre exemple, <livre>). Un document XML ne peut pas avoir deux racines.
  • Chaque autre élément est un nœud dans l'arbre.
  • Les éléments à l'intérieur d'autres éléments sont des nœuds enfants (<titre> est un enfant de <livre>).
  • L'élément contenant est le nœud parent (<livre> est le parent de <titre> et <auteur>).
  • Les éléments au même niveau sont des nœuds frères (<titre> et <auteur> sont frères).

Visualiser votre XML comme un arbre est la clé pour comprendre comment y naviguer et le requêter. Vous pouvez demander à un parser de « trouver l'élément auteur à l'intérieur de l'élément livre », et il saura exactement comment parcourir l'arbre pour y arriver.

Les règles : bien formé vs. valide

C'est ici que XML tire sa réputation d'être strict. Il y a deux niveaux de « correction ».

1. XML bien formé : C'est l'exigence minimale absolue. C'est comme avoir une grammaire correcte.

  • Doit avoir un, et un seul, élément racine.
  • Chaque balise de début doit avoir une balise de fin correspondante.
  • Les balises sont sensibles à la casse : <Livre> n'est pas la même chose que <livre>.
  • Les éléments doivent être correctement imbriqués. <b><i>texte</i></b> est correct ; <b><i>texte</b></i> est une catastrophe.
  • Les valeurs d'attribut doivent être entre guillemets (" ou ').

Si un document XML n'est pas bien formé, n'importe quel parser lèvera immédiatement une erreur et refusera d'aller plus loin. Sans exception.

2. XML valide : C'est le niveau supérieur. Un document XML est « valide » s'il est bien formé et s'il est conforme à un ensemble de règles prédéfinies appelé un schéma.

Un schéma est comme un plan ou un contrat. C'est un fichier séparé (généralement un .xsd ou .dtd) qui définit des choses comme :

  • Quels éléments sont autorisés ?
  • Dans quel ordre doivent-ils apparaître ?
  • Quels éléments sont obligatoires et lesquels sont optionnels ?
  • Quels attributs un élément peut-il avoir ?
  • Le contenu d'un élément est-il censé être un nombre, une chaîne de caractères ou une date ?

Par exemple, un schéma pour notre exemple de livre pourrait dire : « Chaque élément <livre> DOIT avoir un <titre> et au moins un <auteur>. Il PEUT avoir un attribut langue. L'élément <prix>, s'il existe, DOIT contenir un nombre positif. »

C'est le super-pouvoir de XML. Il permet à deux systèmes (par exemple, un acheteur et un vendeur) de s'accorder sur un contrat de données rigide. Toute donnée qui viole le contrat est automatiquement rejetée, prévenant ainsi d'innombrables bugs et malentendus.

Histoires vécues

L'API bancaire qui n'avait pas le droit à l'erreur

Une grande banque développait un système pour que ses grands comptes entreprise puissent soumettre des instructions de paiement automatiquement. On parle de millions de dollars par transaction. Il n'y avait aucune marge d'erreur. Un symbole de devise manquant ou une décimale mal placée pouvait être catastrophique. L'équipe a choisi XML avec une définition de schéma XML (XSD) stricte. Avant même qu'une instruction de paiement ne soit examinée par le système bancaire central, elle était validée par rapport au schéma. Si un client envoyait <montant>100,000</montant> au lieu de <montant>100000.00</montant>, ou <devise>usd</devise> au lieu de <devise>USD</devise>, l'API le rejetait instantanément avec une erreur claire pointant la violation du schéma. La leçon : Pour les échanges de données critiques où l'ambiguïté peut coûter une fortune, la rigueur d'un document XML validé est une fonctionnalité (feature), pas un bug.

Le graphique vectoriel qui n'était que du texte

Un développeur web avait besoin d'un logo complexe pour un nouveau site. Un designer lui a envoyé un fichier .svg. Le développeur, curieux, a ouvert le fichier dans un éditeur de texte et a été surpris de voir que ce n'était pas un blob binaire de pixels. C'était du XML ! Des balises comme <svg>, <path> et <circle> décrivaient les formes, les couleurs et les coordonnées. Il a réalisé qu'il pouvait changer les couleurs du logo par programmation juste en trouvant et remplaçant des valeurs d'attributs dans le XML, sans jamais ouvrir de logiciel de graphisme. Il l'a même animé en manipulant les nœuds XML avec du JavaScript. La leçon : De nombreux formats de fichiers puissants que vous utilisez quotidiennement, comme SVG (Scalable Vector Graphics), sont en fait des dialectes spécifiques de XML, ce qui les rend inspectables, modifiables et scriptables.

La Menace de la configuration antique

Un développeur junior a été chargé de corriger un bug sur une application d'entreprise Java vieille de 15 ans. La source du problème se trouvait quelque part dans la configuration. À son grand effroi, la config n'était pas un simple fichier texte ; c'était un unique fichier XML de 25 000 lignes appelé config.xml. C'était un fouillis non indenté et incompréhensible. Essayer de le lire était impossible. Mais ensuite, il l'a chargé dans un visualiseur XML. Instantanément, l'outil l'a formaté, a ajouté de la coloration syntaxique et lui a permis de réduire d'énormes sections de l'arbre. Il a pu rechercher la section pertinente (<databaseConnectionPool>), voir toute la branche de paramètres associés et repérer immédiatement une faute de frappe dans un nom de serveur. La leçon : XML peut être terriblement verbeux, mais sa structure en arbre inhérente, lorsqu'on la regarde avec les bons outils, rend gérables même les fichiers les plus monstrueusement complexes.

Erreurs et pièges courants

  • Le confondre avec HTML. Ils ont l'air cousins, mais ils n'ont pas le même rôle. HTML est pour la présentation (l'apparence des choses). XML est pour la description des données (ce que sont les choses). Votre navigateur pardonnera un HTML négligé ; un parser XML ne pardonnera pas un XML négligé.
  • L'angoisse du choix attributs vs. éléments. Les débutants se retrouvent souvent coincés sur la question de savoir si une donnée doit être un attribut (<livre isbn="123">) ou un élément enfant (<livre><isbn>123</isbn></livre>). Il n'y a pas de bonne réponse unique, mais une directive courante est que les éléments contiennent du contenu, tandis que les attributs contiennent des métadonnées sur ce contenu. Ne vous prenez pas trop la tête avec ça, mais soyez cohérent.
  • Essayer de le parser avec des expressions régulières. Ne le faites pas. Vraiment pas. Ça semble tentant pour des cas simples, mais comme XML est une structure imbriquée et récursive, une simple regex échouera de manière spectaculaire sur tout fichier non trivial. C'est une histoire d'horreur classique en programmation. Utilisez toujours une vraie bibliothèque de parsing XML pour votre langage de prédilection.
  • Oublier que la casse est sensible. Si votre schéma attend <nom>, envoyer <Nom> provoquera une erreur de validation. Cela piège les développeurs venant de formats moins pointilleux.
  • Ignorer les espaces de noms (namespaces). Dans de grands documents XML qui mélangent différents vocabulaires (par exemple, un mélange de SVG et XSLT), vous verrez des balises comme <xsl:template> ou <svg:path>. Cette partie xsl: est un espace de noms, qui évite un conflit si les deux vocabulaires avaient une balise nommée <template>. Ils peuvent être un casse-tête, mais ils sont essentiels pour les documents complexes.

Pourquoi ça devrait vous intéresser

Vous n'allez probablement pas démarrer un nouveau projet en choisissant XML pour une API simple (JSON gagne généralement la palme de la concision). Mais vous allez tomber sur du XML, c'est garanti. Vous devriez penser à XML quand :

  • Vous intégrez des systèmes d'entreprise plus anciens, surtout ceux utilisant SOAP ou WSDL.
  • Vous devez définir un contrat de données solide comme le roc et incassable entre deux parties (en utilisant XSD).
  • Vous travaillez avec des données orientées document, comme les flux RSS/Atom, les documents Office (OOXML) ou les graphiques vectoriels (SVG).
  • Vous configurez des outils de l'écosystème Java (comme Maven ou Ant) ou .NET.
  • Vous recevez un fichier se terminant par .xml, .svg, .rss, .atom, ou .plist et devez comprendre sa structure, pas seulement son contenu.

Connaître les bases de XML, c'est comme savoir comment fonctionne un carburateur. Vous conduisez peut-être une voiture moderne à injection, mais cette connaissance vous donne une compréhension plus profonde des moteurs et fait de vous un bien meilleur mécanicien lorsque vous êtes face à un modèle classique.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Visionneuse XML