Standards

XML vs HTML : quelle est la différence ?

• VersionDude
• Standards
• 5 min de lecture

Ils se ressemblent, mais XML et HTML ont été conçus pour des tâches différentes — l'un décrit des documents pour les navigateurs, l'autre transporte des données structurées.

HTML et XML se ressemblent étonnamment, et pour une bonne raison : tous deux descendent de SGML et tous deux utilisent la même syntaxe à chevrons de balises, d'attributs et d'éléments imbriqués. À première vue, un extrait de chacun peut être difficile à distinguer de l'autre. Mais la ressemblance de surface cache une profonde différence d'intention, et confondre les deux conduit à beaucoup d'attentes mal placées quant à la façon dont chacun devrait se comporter.

Point crucial, le HTML est délibérément indulgent envers les erreurs, et c'est une fonctionnalité plutôt qu'un oubli. Le standard définit des règles détaillées de récupération d'erreurs de sorte que même un balisage mal écrit produise tout de même une page utilisable, ce qui explique pourquoi une si grande partie du web s'affiche malgré son invalidité technique. Cette tolérance garde le web résilient et accessible, au prix de laisser passer silencieusement les erreurs.

XML a été conçu dans un but presque opposé. Il ne définit aucune balise propre ; au lieu de cela, c'est un méta-langage, un ensemble de règles pour inventer vos propres vocabulaires de balisage afin de transporter des données structurées. Là où HTML vous remet un vocabulaire fixe, XML vous remet la grammaire avec laquelle construire n'importe quel vocabulaire dont vous avez besoin, que ce soit pour des dossiers financiers, des formats de documents ou de la configuration.

Cette flexibilité s'accompagne de rigueur, qui est l'autre moitié du caractère de XML. Un document qui n'est pas bien formé — avec chaque balise fermée et chaque élément correctement imbriqué — est rejeté d'emblée plutôt que réparé. Il n'y a pas de récupération d'erreurs sur laquelle se rabattre ; l'analyseur refuse de poursuivre. Cette posture intransigeante est précisément ce qui rend XML fiable pour l'échange de machine à machine, car soit les données sont structurellement correctes, soit elles ne sont tout simplement pas acceptées du tout.

Les deux philosophies reflètent précisément leurs cas d'usage. La tolérance du HTML convient à un web où d'innombrables auteurs de compétences variées publient des documents qui doivent tout de même s'afficher pour les lecteurs. La rigueur du XML convient aux systèmes qui échangent des données automatiquement, où un document silencieusement mal interprété pourrait corrompre un processus en aval. Aucune approche n'est supérieure dans l'absolu ; chacune est la bonne réponse à un problème différent.

Entre les deux se trouve XHTML, qui est essentiellement du HTML exprimé sous les règles strictes de XML. Un document XHTML doit être du XML bien formé en plus d'être du HTML valide, combinant le vocabulaire web du HTML avec la discipline intransigeante du XML. Il a connu une période de popularité, mais la rigueur qui le rendait séduisant en théorie le rendait aussi fragile en pratique, puisqu'un seul fragment malformé pouvait casser une page entière.

Dans le développement web moderne, le paysage pratique s'est stabilisé. HTML5 est le standard pour construire des pages que les gens lisent dans les navigateurs, ayant absorbé les leçons de ses prédécesseurs comme de l'expérience XHTML. XML et les formats qui en dérivent, quant à eux, restent répandus pour les fichiers de configuration, les flux de données comme RSS et Atom, les formats de documents bureautiques, et bien d'autres endroits où des données structurées doivent être stockées ou échangées.

Il est aussi utile de se rappeler que XML voyage rarement seul ; il ancre toute une famille de technologies apparentées. Des schémas comme DTD et XSD définissent et valident la structure d'un vocabulaire XML particulier, XSLT transforme le XML d'une forme à une autre, et XPath navigue à l'intérieur d'un document. Cet écosystème environnant fait partie des raisons pour lesquelles XML perdure dans les domaines à forte intensité de données, longtemps après s'être effacé de la rédaction de pages front-end.

Une règle empirique utile résume la distinction proprement. Tournez-vous vers HTML lorsque vous décrivez un document destiné à être lu par des personnes dans un navigateur, et vers les formats de la famille XML lorsque vous échangez ou stockez des données structurées entre systèmes. Une fois que vous cadrez le choix autour du but plutôt que de l'apparence, le chevauchement apparent entre les deux se dissout, et il devient évident quel outil chaque tâche appelle.