XML in YAML umwandeln

Wer eine Datenschutz-Folgenabschätzung für eine App schreibt, muss irgendwann jede angeforderte Berechtigung in einer AndroidManifest.xml nachvollziehen — und genau die ist als XML-Baum mit verschachtelten <uses-permission>-Elementen praktisch nicht auf einen Blick zu lesen. Dieselbe Situation entsteht bei jeder größeren Konfiguration, die geprüft statt bloß ausgeführt werden soll: ein web.config, ein pom.xml, eine Build-Pipeline.

Als YAML steht dieselbe Information in Einrückung statt in Klammern, und eine Prüfung, die vorher zwanzig Minuten Scrollen brauchte, passt danach auf einen Bildschirm. Nichts an der eigentlichen Konfiguration ändert sich dabei — nur die Lesbarkeit.

XML verbraucht rund die Hälfte seiner Zeichen allein dafür, zu sagen, wo ein Element endet. YAML sagt das über Einrückung, dieselbe Datei wird dadurch deutlich kürzer, und jede Verschachtelungsebene ist ein optischer Schritt statt ein Klammerpaar, das gesucht werden muss.

Die Struktur selbst bleibt unverändert. Jedes Element wird zu einem Schlüssel, seine Kindelemente werden zur Zuordnung darunter, Text wird zum Wert. Nichts wird umsortiert oder zusammengefasst — was hier steht, ist dasselbe Dokument ohne die Zeichensetzung, und genau das braucht, wer verstehen will, was eine Datei tatsächlich aussagt.

Attribute kommen als Schlüssel mit vorangestelltem @ herüber, und ein Element, das gleichzeitig Attribute und Text trägt, speichert diesen Text unter dem Schlüssel #text. Beide werden in Anführungszeichen geschrieben, weil YAML das @ als reserviertes Zeichen am Anfang eines einfachen Wertes behandelt und ein # einen Kommentar einleitet.

Das sieht nach Rauschen aus und ist Korrektheit. Wer die Datei von Hand bearbeitet, sollte diese Anführungszeichen stehen lassen — sie zu entfernen ergibt entweder YAML, das nicht mehr geparst werden kann, oder verwandelt bei #text den Rest der Zeile stillschweigend in einen Kommentar und löscht den Wert.

Das ist der stärkste Grund für die Umwandlung. XML zu diffen ist mühsam, weil eine Änderung eine Ebene tief als mehrere Zeilen Tags erscheint und eine automatische Neuformatierung gleich die ganze Datei umschreibt. Werden beide Versionen umgewandelt und die YAML-Dateien verglichen, stehen die geänderten Werte auf eigenen Zeilen, mit ihrem Pfad direkt darüber.

Eine Sache entscheidet dabei über Erfolg oder Verwirrung: Weil ein einzeln vorkommendes Element eine Zuordnung wird und zwei davon eine Liste, ändert eine hinzugefügte zweite Abhängigkeit die Form dieses Zweigs und nicht nur seinen Inhalt — der Diff zeigt dann den ganzen Block als geändert an. Das ist kein Informationsverlust, sondern eine echte Formänderung, und das vorher zu wissen bewahrt davor, einen großen Diff als große inhaltliche Änderung misszuverstehen.

Präfixe bleiben Teil des Schlüsselnamens, sodass ein Dokument mit soap: oder xsi: Schlüssel mit einem Doppelpunkt darin erzeugt. Der Schreiber gibt sie unquotiert aus, und dieselbe Bibliothek liest sie beim erneuten Einlesen korrekt zurück. Die Namensraum-Deklaration selbst kommt als Attribut an, ein Standard-xmlns landet also als gequoteter „@xmlns"-Schlüssel auf der Wurzel.

Ein Doppelpunkt in einem unquotierten Schlüssel ist trotzdem ein Kandidat für eine manuelle Korrektur, bevor die Datei weiterreist. Soll die YAML-Datei von einem anderen Werkzeug gelesen werden, lohnt es sich, diese Schlüssel selbst in Anführungszeichen zu setzen — das kostet nichts und verhindert eine Fehlerklasse, die erst beim nächsten Parser auftaucht. Aufgelöst werden Präfixe zu ihren Namensraum-URIs dabei nicht, zwei Dokumente mit unterschiedlichen Präfixen für denselben Namensraum lassen sich also nicht sauber gegeneinander diffen.

Werte, die wie Zahlen aussehen, werden geparst, in Elementtext genauso wie in Attributen. Eine Versionsnummer wie 4.13.2 bleibt Text, weil sie zwei Punkte enthält und keine Zahl sein kann, ebenso eine Adresse oder ein Pfad. Ein als 1.0 geschriebenes Attribut wird dagegen zur 1, und eine mit Nullen aufgefüllte Zahl wie 007 wird zur 7.

Bei einer Konfiguration, die nur gelesen wird, bleibt der Schaden auf die Optik beschränkt — und trotzdem relevant: Eine Schemaversion, die bei der Prüfung als 1 statt als 1.0 auftaucht, ist ein Wert, den jemand hinterfragt oder, schlimmer, weiterkopiert. Ein einmaliger Blick über die zahlenartigen Werte in der Ausgabe lohnt sich, insbesondere wenn die YAML-Datei über den eigenen Bildschirm hinaus wandert.

Ein Wert mit Zeilenumbrüchen wird als Block-Skalar geschrieben — ein Pipe-Zeichen mit eingerücktem Text darunter — statt in eine Zeile gequetscht zu werden. Ein langer einzeiliger Wert bleibt, wie er ist, ohne Umbruch. Beides ist die richtige Entscheidung für eine Datei, die zum Lesen gedacht ist.

Ein leeres oder selbstschließendes Element wird zu einer leeren Zeichenkette. XML unterscheidet nicht zwischen einem leeren Element und einem, das nichts enthält, es geht also nichts verloren — nur ist eine leere Zeichenkette in einer langen Datei leicht zu übersehen. Wer eine Konfiguration auf nicht gesetzte Werte prüft, sucht besser gezielt nach den leeren Anführungszeichen, als sich auf das Auge zu verlassen.

XML unterstützt Kommentare, YAML auch, und keiner der eigenen überlebt. Der Parser verwirft sie, und nichts schreibt sie zurück. Bei einer reinen Nutzlast ist das unerheblich; bei einer Build-Konfiguration ist es oft der größte Verlust, weil der Kommentar über einer festgepinnten Abhängigkeitsversion meistens die einzige noch vorhandene Erklärung ist, warum sie festgepinnt wurde.

Die tragfähige Regel ist, die YAML-Datei als Lesekopie zu behandeln und das XML als Quelle zu bewahren. Soll die YAML-Datei stattdessen die neue Quelle werden — eine echte Migration in ein Ansible- oder Helm-Projekt —, gehört das Übertragen der Kommentare als eigener Arbeitsschritt eingeplant, bevor die XML-Datei gelöscht wird und die Begründungen mit ihr verschwinden.

Eine umgewandelte Konfiguration ist noch keine fertige Values- oder Variablen-Datei. Sie trägt XML-Spuren mit sich — die @-Schlüssel, die #text-Schlüssel, eine Namensraum-Deklaration auf der Wurzel, möglicherweise einen ?xml-Schlüssel aus der Deklarationszeile —, die für das Zielwerkzeug bedeutungslos sind. Diese zu löschen ist der erste Durchgang.

Der zweite betrifft die Benennung. XML-Elementnamen sind oft ausführlicher, als es ohne das dazugehörige Schema nötig wäre, und eine YAML-Konfiguration will sie üblicherweise kürzer und flacher. Beide Durchgänge sind Handarbeit und zugleich die eigentliche Migration — die Umwandlung liefert nur den lesbaren Ausgangspunkt statt einer Wand aus Tags.

Umwandeln lohnt sich, wenn das Ziel Verstehen, Prüfen oder Vergleichen ist: Die YAML-Datei ist kürzer, die Struktur ist offensichtlich, und alles läuft im Browser in der Zeit, die das Ablegen der Datei braucht. Eine gute Angewohnheit für jede Konfiguration, die man übergeben bekommt und nachvollziehen muss, bevor man sie ändert.

Nicht umwandeln, wenn die Datei gegen ein Schema geprüft, signiert wird oder von einem Werkzeug gelesen wird, das XML erwartet. Das XML bleibt in diesem Fall der eigentliche Bestand, und eine YAML-Kopie wäre eine zweite Version der Wahrheit, die früher oder später von der ersten abweicht. Lesen als YAML, ändern als XML.

Kubernetes-Manifeste, GitLab-CI-Pipelines und Ansible-Playbooks sind in vielen deutschen IT-Abteilungen — gerade dort, wo aus Datenschutzgründen selbst gehostete GitLab-Instanzen statt cloud-basierter Dienste laufen — längst in YAML verfasst. Eine alte XML-Konfiguration, die in genau diese Landschaft übernommen werden soll, wirkt neben all dem fremd, bevor überhaupt über ihren Inhalt gesprochen wird.

Wer eine solche Datei ins Team bringt, tut sich leichter, wenn sie zumindest in der Optik zu allem anderen im Repository passt. Die Umwandlung macht aus der XML-Datei keine fertige Ansible-Variable, aber sie sorgt dafür, dass beim Code-Review niemand zuerst über die Syntax stolpert, bevor er über den eigentlichen Inhalt nachdenkt.

Eine Konfiguration, die es wert ist, gelesen und verstanden zu werden, enthält oft genau die Werte, die niemand freiwillig in ein fremdes Webformular einträgt: Datenbank-Zugangsdaten, interne Serveradressen, Lizenzschlüssel. Weil Parser und YAML-Schreiber vollständig als JavaScript in dieser Seite laufen, verlässt eine solche Datei den eigenen Rechner zu keinem Zeitpunkt.

Für eine IT-Abteilung mit eigener Sicherheitsrichtlinie ist das oft keine Nebensächlichkeit, sondern die Bedingung dafür, ein Werkzeug wie dieses überhaupt einsetzen zu dürfen — unabhängig davon, wie gut ein alternativer, serverseitig arbeitender Dienst die eigentliche Umwandlung sonst beherrschen mag.

Wer die YAML-Ausgabe zum ersten Mal in einem Editor öffnet, tut sich leichter, wenn XML-Original und YAML-Ansicht nebeneinander sichtbar bleiben — die meisten Code-Editoren erlauben eine geteilte Ansicht genau dafür. So lässt sich jeder auffällige Wert sofort im ursprünglichen Kontext nachschlagen, statt sich auf das Gedächtnis zu verlassen, was ein bestimmter Pfad im Original bedeutet hat.

Diese Gewohnheit zahlt sich besonders bei der ersten Konfiguration eines unbekannten Projekts aus, wenn noch niemand im Team die Struktur auswendig kennt. Der Blick zurück ins Original kostet einen Tastendruck und verhindert, aus einer verkürzten YAML-Ansicht eine falsche Annahme über den ursprünglichen Aufbau der Datei mitzunehmen.