Convertir YAML en XML

Toute la conversion tient dans cette phrase. Un fichier YAML est un arbre de clés et de valeurs, et un fichier XML est un arbre d’éléments, avec en option des attributs et du texte. La projection doit décider laquelle des deux formes de XML représente chaque morceau du YAML, et le registre marque cette conversion comme approximative précisément parce que cette décision est un choix que le convertisseur fait à votre place.

La règle appliquée ici est la plus simple et la plus prévisible : chaque clé devient un élément, et la valeur scalaire devient le texte de cet élément. Un attribut n’est jamais créé à partir d’une clé, parce que YAML n’a aucune convention pour distinguer « ceci est un attribut » de « ceci est un enfant ». C’est une perte pour les fichiers qui auraient voulu des attributs, et c’est volontaire.

Une paire clé-valeur YAML devient un élément XML du nom de la clé, avec la valeur comme contenu textuel. name: Alice devient <name>Alice</name>, et les chaînes qui contiennent des caractères spéciaux sont échappées, ce qui est la différence entre un fichier lisible et un fichier que XML analyse correctement. Un « & » devient &amp;, un « < » devient &lt;, et un guillemet droit est protégé par les conventions de l’attribut ou par une section CDATA si la valeur en contient beaucoup.

Une valeur numérique YAML est émise comme la représentation textuelle, parce que XML n’a pas de type. C’est sans perte pour un aller-retour réalisé par un consommateur qui sait interpréter la chaîne, et c’est une perte pour un consommateur qui attendait un type. La convention consiste à écrire le nombre dans YAML, à le lire comme chaîne en XML, et à laisser le code de l’application le convertir au moment où il en a besoin.

Une clé dont la valeur est un objet YAML devient un élément XML qui contient d’autres éléments, un par clé de l’objet. La structure est préservée exactement : un objet à trois clés produit un parent avec trois enfants, et le nombre de niveaux d’imbrication YAML se traduit en niveaux d’imbrication XML. C’est la conversion la plus propre de ce groupe de pages, et c’est la raison pour laquelle YAML est un format d’échange viable quand le consommateur exige du XML.

L’ordre des clés est préservé, ce que ni YAML ni XML ne garantit formellement pour les mappings. La conversion préserve donc ce qu’elle trouve, ce qui est ce que la grande majorité des fichiers en circulation suppose. Si le fichier YAML a été produit par un outil qui réordonne, XML aura le même ordre, et la différence entre deux exports sera plus facile à lire.

Un tableau YAML devient une suite d’enfants XML de même nom, sans marqueur de la liste. C’est la convention XML classique : un parent <hosts> contient trois enfants <host>, et un consommateur qui veut savoir combien il y en a compte les enfants. La conversion adopte cette convention parce qu’elle est universelle et qu’elle est ce que toute grammaire XML en circulation reconnaît.

Un consommateur strict qui veut distinguer « un enfant » de « une suite d’enfants » peut le faire en regardant le type du contenu : un texte seul versus plusieurs enfants du même nom. C’est une convention qu’un schéma XSD peut exprimer, et qu’une application peut implémenter en deux lignes. Pour un aller-retour, c’est suffisant et c’est ce que la conversion fournit.

YAML permet à une clé d’être explicitement null, et la conversion écrit un élément vide à sa place. C’est la représentation XML classique d’une valeur absente : <key></key> ou <key/>. Un consommateur qui veut distinguer « clé absente » de « clé présente et vide » doit vérifier la présence de l’élément, pas son contenu.

C’est cohérent avec ce que XML attend, et c’est volontaire. La conversion ne génère jamais la chaîne « null » comme contenu, parce que cette chaîne ne distingue pas la valeur explicite de la chaîne littérale. Pour un fichier qui veut marquer l’absence d’une valeur, l’élément vide est la bonne forme, et un aller-retour la préserve.

YAML permet de définir un bloc une fois (&id) et de le référencer à plusieurs endroits (*id). XML n’a aucune notion d’alias, donc chaque référence est développée en une copie complète du bloc. Le résultat est correct et plus volumineux, et c’est le compromis à accepter pour passer d’un format à l’autre.

Pour un fichier de configuration typique, c’est indolore parce que les sections partagées sont petites. Pour un fichier où la même structure lourde est référencée vingt fois, la sortie sera vingt fois plus longue que la source, et la compression en aval ne récupérera qu’une partie. Si la taille compte, déplier les ancres à la main en YAML avant la conversion est l’édition qui vaut la peine.

YAML autorise un commentaire n’importe où sur une ligne, après un dièse. XML a la même convention avec <-- … -->, et la conversion ne transporte pas les commentaires parce que la sortie est générée sans contexte. Pour les réintroduire, l’édition manuelle est la seule voie, et c’est le bon moment pour les écrire parce que la forme XML rend la section commentaire visible et correctement encadrée.

Un scalaire bloc YAML avec un pipe devient une chaîne multi-lignes dans un élément XML. La convention XML pour une chaîne multi-lignes est une section CDATA, qui porte le texte tel quel sans échappement. La conversion utilise CDATA quand la chaîne contient des caractères qui demanderaient un échappement, ce qui rend la sortie lisible et exacte.

Un document YAML est implicitement un objet racine. Le XML exige un élément racine unique, et la conversion enveloppe le contenu dans un élément <root> quand la source est un mapping de premier niveau. Le nom de l’élément racine est configurable, et le défaut est <root>, ce qui est lisible mais qu’un schéma en aval refusera peut-être.

Le cas d’une séquence YAML au plus haut niveau est intéressant : la conversion enveloppe la liste dans un élément racine, et chaque élément de la liste devient un enfant répété. C’est la convention XML pour un tableau, et un consommateur qui lit la sortie peut compter les enfants pour retrouver le nombre d’enregistrements.

XML a cinq caractères qui doivent être échappés dans le contenu d’un élément : <, >, &, l’apostrophe droite et le guillemet droit. La conversion échappe les quatre premiers systématiquement, et le cinquième seulement quand le contexte l’exige. Le résultat est un fichier que tout parseur XML conforme lit correctement, et un fichier qui n’est pas lisible par accident comme du HTML quand un navigateur l’ouvre.

Pour une chaîne qui contient beaucoup de ces caractères, l’utilisation d’une section CDATA est lisible et préserve le texte tel quel. La conversion choisit CDATA quand la chaîne est longue et contient au moins un caractère à échapper, ce qui est la convention que la plupart des auteurs XML adoptent. C’est sans perte et c’est ce qu’un aller-retour avec un autre outil produirait.

C’est du JavaScript dans votre onglet. Le YAML est analysé par un parseur chargé à la demande, XML est écrit par une bibliothèque qui tourne dans l’onglet, et aucune requête ne porte le document. Il n’y a pas d’inscription, pas de file d’attente, et le niveau gratuit accepte jusqu’à 100 Mo.

Pour ce lectorat, c’est une préoccupation pratique plutôt qu’abstraite. Un manifeste de configuration contient des noms d’hôtes internes, des chemins de registres et des secrets, et un certain nombre d’organisations traitent le fait de coller cela dans un convertisseur web public comme un incident. Ici il n’y a rien à coller et rien à envoyer, et le code du parseur tourne dans l’onglet.