XML et modèles de données

Définition

XML (eXtensible Markup Language) décrit l'information par des balises imbriquées formant une arborescence : chaque donnée est portée par un élément nommé, qui peut avoir des attributs et des enfants. Un modèle de données (YANG en contexte réseau) est une spécification formelle de cette arborescence : quels éléments existent, leurs types, leurs relations. XML porte le document, le modèle définit le vocabulaire autorisé.

Contexte

Le blueprint 200-301 v1.1, topic 6.7, demande de reconnaître la structure et les composants des données XML, aux côtés de JSON et YAML. Attendu à l'examen : identifier une balise ouvrante/fermante, un attribut, la racine, lire une imbrication ; savoir que XML est le format historique des protocoles réseau model-driven (NETCONF, et RESTCONF en option) et qu'il sert de base à YANG. Aucune rédaction de XML complet n'est demandée, seulement de la lecture.

Anatomie d'un document XML

Un élément s'écrit <nom>contenu</nom> ; un élément vide peut s'écrire <nom/>. Trois règles structurelles : un document n'a qu'une seule balise racine, tout élément ouvert doit être fermé, et les balises ne se croisent pas (imbrication stricte). Les attributs portent des métadonnées dans la balise ouvrante, les éléments portent la donnée elle-même.

<?xml version="1.0" encoding="UTF-8"?>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
  <interface name="GigabitEthernet1" enabled="true">
    <description>Liaison uplink campus</description>
    <ipv4>
      <address>
        <ip>10.10.10.1</ip>
        <prefix-length>24</prefix-length>
      </address>
    </ipv4>
  </interface>
</interfaces>

Lecture de ce bloc : interfaces est la racine, name et enabled sont des attributs, description est un élément à contenu texte, address est imbriqué à trois niveaux. La déclaration <?xml ... ?> en tête est le prolog optionnel qui fixe version et encodage. L'espace de noms xmlns est une URL d'identifiant (ici celle du modèle ietf-interfaces, standard IETF) : personne ne la visite, elle distingue les vocabulaires qui pourraient entrer en collision.

Pour cibler un noeud sans parcourir tout l'arbre, XPath est le langage de requête d'XML : /interfaces/interface[@name='GigabitEthernet1']/ipv4/address/ip sélectionne l'adresse IP de cette interface. Au CCNA, il suffit de reconnaître cette syntaxe de chemin ; la plume complète est hors périmètre.

XML face à JSON

Critère	XML	JSON
Unité de structure	élément/balise	paire clé/valeur, tableau
Racine	une seule, obligatoire	objet ou tableau
Métadonnées	attributs dans la balise	simples valeurs
Types de données	tout est texte, typage par schéma	string, number, booléen, null natifs
Commentaires	autorisés	interdits
Volume	verbeux (balises fermantes)	compact
Schéma	XSD, et YANG en réseau	aucun natif

La verbosité d'XML est son prix, sa richesse aussi : attributs, espaces de noms, prolog, stylesheets. Le même payload ci-dessus pèse environ 330 octets en XML contre 180 en JSON. Pour des API modernes entre scripts légers, JSON gagne largement ; pour des protocoles normalisés qui doivent décrire un vocabulaire complet et extensible, cette richesse est précisément ce qu'on paie.

XML, YANG et NETCONF

C'est ici que XML croise le réseau. YANG est un langage de modélisation : il décrit des modules (conteneurs, listes, leafs, types, contraintes) dont la version sérialisée sur le fil est XML (RFC 6020/7950 pour le modèle, RFC 7951 pour le binding XML). NETCONF (RFC 6241) est le protocole RPC qui transporte des documents XML pour lire, modifier et versionner la configuration d'un équipement, typiquement sur TCP 830. Un échange NETCONF <get-config> répond une arborescence XML conforme au modèle YANG de l'appareil : chaque balise du document correspond à un noeud déclaré dans le modèle.

<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><running/></source>
    <filter type="subtree">
      <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"/>
    </filter>
  </get-config>
</rpc>

RESTCONF, la variante HTTP de cet édifice, accepte XML (application/yang-data+xml) comme JSON (application/yang-data+json) : voir . Le point d'examen à retenir : les données model-driven voyagent historiquement en XML structuré par YANG, alors que le REST générique utilise JSON.

Exemple concret chiffré

Un collecteur de télémétrie interroge 12 routeurs IOS XE en NETCONF sur TCP 830 pour aspirer leur configuration running complète, chaque nuit à 02h00. Mesure sur un device moyen : 240 Ko de reply XML contre le tiers environ en équivalent JSON CLI dump, soit un total de 2,9 Mo aspirés par nuit sur la liaison de management à 2,9 Mbps de moyenne, soit 1 seconde de trafic utile. Le gain d'XML n'est pas la taille : c'est la garantie de structure. En une année, le parser XML n'a rencontré aucun cas « l'interface s'appelait Gi1/0/24 et non GigabitEthernet1 » parce que le modèle YANG impose les noms de noeuds ; le parseur regex sur sortie CLI, lui, a cassé 3 fois lors de montées de version IOS. C'est tout l'argument des modèles de données contre le text scraping.