XML-Formatierer

Ein auf regulären Ausdrücken gebauter Formatierer — der vor jedem `<` einen Zeilenumbruch einfügt und nach einer laufenden Zählung offener Tags einrückt — funktioniert bei einfachem, handgeschriebenem XML passabel und scheitert bei echten Dokumenten aus Gründen, die leicht zu übersehen sind, bis sie eine beschädigte Datei verursachen. Ein CDATA-Abschnitt, geschrieben als `<![CDATA[...]]>`, existiert speziell, um beliebigen Text zu enthalten, der selbst wie Tags aussehende Zeichen enthalten könnte, und ein nach `<` suchender regulärer Ausdruck hat keine Möglichkeit zu wissen, dass er alles zwischen diesen Markern ignorieren sollte, statt den Inhalt als Struktur zu behandeln. Kommentare tragen dasselbe Risiko, und Attributwerte sind noch schlimmer: Ein Attribut wie `note="a > b"` enthält ein literales `>`-Zeichen, das ein naiver Scanner mit dem Ende des Tags verwechseln kann, was es still an der falschen Stelle abschneidet.

XML korrekt zu formatieren bedeutet, dass der Scanner diese speziellen Bereiche erkennen muss — CDATA-Blöcke, Kommentare, Verarbeitungsanweisungen, DOCTYPE-Deklarationen, und Attributwerte in Anführungszeichen — bevor er nach irgendetwas sucht, das wie Tag-Struktur aussieht, damit deren Inhalt Byte für Byte übertragen wird statt als Markup neu interpretiert zu werden.

Dieses Tool prüft, dass jedes Tag korrekt geschlossen und korrekt verschachtelt ist — die strukturellen Regeln, die ein XML-Dokument „wohlgeformt" machen — und meldet das spezifische unausgeglichene oder nicht geschlossene Tag, wenn diese Prüfung scheitert. Was es nicht tut, ist das Dokument gegen ein DTD oder ein XML Schema (XSD) zu validieren, was zusätzlich prüfen würde, ob Elemente, Attribute und ihre spezifischen Werte den Regeln eines bestimmten Dokumenttyps entsprechen — ob ein erforderliches Attribut vorhanden ist, ob ein Element im richtigen Kontext erscheint, ob ein Wert einem erwarteten Datentyp entspricht. Das ist eine wirklich andere und aufwendigere Prüfung, die das Schema-Dokument selbst als zusätzliche Eingabe benötigt, nicht etwas, das ein allgemeiner Formatierer allein aus dem XML ableiten kann.

Striktes XHTML ist gültiges XML und formatiert hier korrekt, aber gewöhnliches echtes HTML ist es aus Gründen nicht, die in die HTML-Spezifikation selbst eingebaut sind: leere Elemente wie `<br>` und `<img>` werden nie geschlossen und haben überhaupt kein schließendes Tag, mehrere Tags haben optionale schließende Tags, die Browser automatisch ableiten, und Browser tolerieren fehlerhafte Verschachtelung, die strikte XML-Analyse direkt ablehnen würde. Ein strikter XML-Formatierer, auf typisches HTML angewendet, würde auf jeder völlig normalen, wohlgeformten Seite Fehler melden, weshalb HTML genau deshalb einen separaten Formatierer hat, der um einen echten HTML-Parser gebaut ist, der diese HTML-spezifischen Regeln versteht, statt das Dokument als strikte XML zu behandeln.

JSON hat XML als Standardwahl für neue Web-APIs abgelöst, aber ein Großteil der Infrastruktur wurde vor diesem Wechsel gebaut und läuft immer noch darauf: SOAP-Webdienste, RSS- und Atom-Feeds, SVG-Bilder (die selbst XML sind), Office-Dokumentformate intern, und ein langer Schwanz von Unternehmenssystemen und Konfigurationsformaten, die älter als die Popularität von JSON sind. Jeder, der sich in eines dieser älteren oder formelleren Systeme integriert, muss noch wohlgeformtes XML lesen, debuggen und erzeugen, was genau das Publikum ist, dem ein dedizierter XML-Formatierer weiterhin dient, selbst wenn XML im Design neuer APIs zurückgegangen ist.