XML wird gern als überholt beschrieben, was merkwürdig ist, da Sie heute fast sicher mehrere XML-Dateien geöffnet haben, ohne es zu merken. Den Streit um das Versenden von Daten zwischen Programmen hat es verloren — JSON gewann ihn deutlich. Alles andere hat es behalten.
XML steht für Extensible Markup Language. Es sieht aus wie HTML, mit einem entscheidenden Unterschied: In HTML sind die Tags festgelegt, in XML erfinden Sie sie selbst.
<book>
<title>Die Reise nach Westen</title>
<year>1592</year>
</book>
Nichts definiert <book> im Voraus. Das Format liefert die Grammatik — Tags, Verschachtelung, Attribute — und Sie liefern das Vokabular, das Ihre Daten brauchen.
.docx ist ein Zip-Archiv voller XML; Text, Formatierung und Struktur sind XML-Dateien darin.Das ist keine Altlastenliste. Dort hat sich XML als richtig erwiesen.
Nehmen Sie einen Satz mit Hervorhebung darin: der flinke braune Fuchs, wobei nur „flinke” kursiv ist. In XML ist das natürlich:
<p>der <em>flinke</em> braune Fuchs</p>
Text und Auszeichnung verschränken sich — XML nennt das gemischten Inhalt. Das Element enthält etwas Text, dann ein Element, dann wieder Text.
JSON hat keine Möglichkeit, das auszudrücken. Seine Werte sind Zeichenkette, Zahl, Liste oder Objekt; den Begriff „Text mit an bestimmten Stellen Eingebettetem” gibt es nicht. Diesen Satz in JSON darzustellen verlangt, eine Konvention zu erfinden — ein Array von Fragmenten, jedes mit seinem Stil versehen — und alle müssen Ihrer Erfindung zustimmen.
Dokumente bestehen aus gemischtem Inhalt. Fast jeder Satz in einem echten Dokument trägt etwas Ausgezeichnetes in sich. Deshalb sind Textverarbeitung, E-Books und Seitenlayout XML — und bleiben es.
Daten sind nicht so. Ein Preis ist eine Zahl, ein Name eine Zeichenkette, eine Bestellung hat eine Liste von Positionen. JSON passt dazu perfekt, XML fügt nur Interpunktion hinzu.
<book id="42"> — Metadaten am Element statt darin.<!-- so -->. JSON hat gar keine, was in Konfigurationsdateien echt stört.<br> ist ungültig; <br/> ist richtig.<Book> und <book> sind verschiedene Elemente.Und dann die, die mehr kaputtes XML verursacht als alle anderen zusammen: das kaufmännische Und.
Fünf Zeichen sind reserviert, und & ist das gefährliche, weil es ständig in URLs vorkommt. Eine Adresse mit Parametern enthält & zwischen ihnen, und roh in XML eingefügt macht es die Datei sofort ungültig. Es muss & geschrieben werden.
Das ist die übliche Ursache, wenn ein Validator eine Sitemap oder einen RSS-Feed ablehnt: ein einziges nicht maskiertes Und-Zeichen in einem Link. Die anderen vier sind <, >, " und ', geschrieben als <, >, " und '.
Für einen Block voller solcher Zeichen markiert <![CDATA[ ... ]]> einen Bereich, den der Parser wörtlich nehmen soll — der Standardweg, HTML in einen RSS-Feed zu legen.
Anders als CSV löst XML das Kodierungsproblem ordentlich. Die erste Zeile erklärt sie:
<?xml version="1.0" encoding="UTF-8"?>
Die Datei sagt, was sie ist, nichts muss raten, und chinesische oder japanische Inhalte überstehen den Weg zwischen Systemen. Eine Kleinigkeit, die eine ganze Fehlerkategorie beseitigt.
XML ist wortreich. Für eine API, die tausendmal pro Sekunde aufgerufen wird, ist das reine Verschwendung, und JSON ist die richtige Antwort.
Für ein Dokument, das in dreißig Jahren lesbar sein, gegen einen veröffentlichten Standard validiert und von zwei Organisationen, die nie miteinander gesprochen haben, identisch ausgelegt werden muss, leistet die Weitschweifigkeit Arbeit. Die Datei beschreibt sich selbst, das Schema definiert, was zulässig ist, und nichts hängt an einer gemeinsamen Annahme, die nie aufgeschrieben wurde.
Das ist die Teilung, die man sich merken sollte: JSON für Daten in Bewegung, XML für Dokumente, die bleiben müssen.
& zerstört die Datei — schreiben Sie &, besonders in URLs