XML im Jahr 2026: Ist es für moderne Entwicklung noch relevant?

Ich gebe es zu — wenn ich „XML" im Jahr 2026 sehe, denke ich zuerst an „Legacy-Code". Aber das ist eigentlich unfair. XML treibt leise einige der wichtigsten Systeme der Welt an, und es wird so schnell nicht verschwinden. Lassen Sie mich Ihnen zeigen, warum.

Wo XML noch das Sagen hat

Bank- und Finanzwesen: Jedes Mal, wenn Sie in Europa eine Banküberweisung machen, läuft sie mit hoher Wahrscheinlichkeit über ISO 20022-Nachrichten — das ist XML. Finanzberichte verwenden XBRL (ebenfalls XML). Wir sprechen von Billionen Dollar, die jeden einzelnen Tag durch XML-Leitungen fließen.

Gesundheitswesen: HL7 FHIR nutzt sowohl JSON als auch XML, aber die älteren HL7 v2/v3-Nachrichten, auf denen die meisten Krankenhaussysteme laufen? Reines XML. Patientenakten, Laborbefunde, Rezepte — alles XML.

Ihre Office-Dokumente: Jede .docx-, .xlsx- und .pptx-Datei ist eigentlich ein ZIP-Archiv voller XML-Dateien. Öffnen Sie mal eine — es ist faszinierend (und ein bisschen erschreckend).

Android-Entwicklung: Jede Layout-Datei in Android ist XML. activity_main.xml ist wahrscheinlich die erste Datei, die jeder Android-Entwickler erstellt.

Build-Tools: Mavens pom.xml, .NETs .csproj-Dateien, Spring-Framework-Konfigurationen — XML ist tief in Unternehmens-Toolchains verankert.

Was XML kann, was JSON nicht kann

Namensräume: Stellen Sie sich vor, Sie kombinieren Elemente aus verschiedenen Vokabularen in einem Dokument ohne Namenskollisionen. XML-Namensräume machen das möglich. Es ist unverzichtbar für Formate wie SVG eingebettet in HTML oder die Mischung von SOAP-Headern mit benutzerdefinierten Payloads.

Gemischter Inhalt: Versuchen Sie, einen Absatz darzustellen, in dem einige Wörter fett und andere kursiv sind, in JSON. Bestenfalls umständlich. XML kann das natürlich, weil es für Dokumente entworfen wurde, nicht nur für Daten.

XSLT-Transformationen: Sie können ein einziges XSLT-Stylesheet schreiben, das XML in HTML, PDF, ein anderes XML-Format oder reinen Text umwandelt. Es ist eine deklarative Transformationssprache ohne echtes Gegenstück in der JSON-Welt.

Schema-Validierung: XML Schema (XSD) ist in vielen Bereichen ausdrucksstärker als JSON Schema. Es kann Elementreihenfolge, komplexe Typhierarchien und feldübergreifende Einschränkungen durchsetzen, mit denen JSON Schema Schwierigkeiten hat.

Ein Praxisbeispiel

Nehmen wir an, Sie bauen ein E-Commerce-System, das Rechnungen generieren muss. Mit XML + XSLT speichern Sie Rechnungsdaten in XML und wenden dann verschiedene XSLT-Stylesheets an, um zu erzeugen: eine HTML-Version für den Browser, eine PDF-Version zum Drucken und eine EDI-Version für das Lieferantensystem — alles aus denselben Quelldaten. Versuchen Sie das mal mit JSON.

XML-Namensräume in Aktion

Namensräume sind eines dieser XML-Features, die verwirrend erscheinen, bis man sie tatsächlich braucht. Hier ist ein praktisches Beispiel — ein SVG-Icon eingebettet in ein XHTML-Dokument:

Ohne Namensräume wüsste der Parser nicht, ob zum HTML-Vokabular oder zum SVG-Vokabular gehört. Namensräume ermöglichen es Ihnen, Vokabulare frei in einem einzigen Dokument zu mischen, und das ist etwas, wofür JSON schlicht keinen Mechanismus hat.

Häufige Fehler, die Entwickler mit XML machen

Nach Jahren der Arbeit mit XML in Produktionssystemen sind hier die Fallstricke, die ich am häufigsten sehe:

1. Encoding-Deklarationen ignorieren. Wenn Ihre XML-Datei Nicht-ASCII-Zeichen enthält, aber Sie die Encoding-Deklaration vergessen, nehmen Parser UTF-8 oder was auch immer ihr Standard ist an. Deklarieren Sie es immer explizit:

2. Attribute verwenden, wenn Elemente mehr Sinn machen. Attribute können keine komplexen Strukturen aufnehmen, können sich nicht wiederholen und lassen sich nicht leicht weiterentwickeln. Wenn ein Wert später an Komplexität zunehmen könnte, verwenden Sie stattdessen ein Kind-Element.

3. Nicht gegen ein Schema validieren. Unvalidiertes XML weiterzureichen ist ein Rezept für stille Fehler. Wenn Sie ein XSD haben, nutzen Sie es. Es fängt Datenprobleme beim Parsen ab, anstatt fehlerhafte Daten durch Ihr System kaskadieren zu lassen.

4. XML durch String-Konkatenation zusammenbauen. Tun Sie das nie — es ist eine Injection-Schwachstelle, die nur darauf wartet, ausgenutzt zu werden. Verwenden Sie immer eine ordentliche XML-Bibliothek oder einen DOM-Builder.

Performance-Tipps für XML-Verarbeitung

XML-Parser gibt es in zwei Hauptvarianten, und die richtige Wahl ist entscheidend für die Performance:

• DOM-Parser laden das gesamte Dokument als Baum in den Speicher. Großartig für kleine bis mittlere Dokumente, bei denen Sie wahlfreien Zugriff brauchen. Schlecht für große Dateien — eine 100-MB-XML-Datei kann als DOM-Baum 1 GB+ RAM verbrauchen.
• SAX/StAX-Parser verarbeiten das Dokument als Stream, ein Element nach dem anderen. Sie verbrauchen fast keinen Speicher und sind viel schneller für große Dateien. Der Nachteil ist, dass man nicht im Dokument hin- und herspringen kann.

Hier die Faustregel: Wenn Ihr XML unter 10 MB ist, ist DOM in Ordnung. Über 10 MB sollten Sie Streaming in Betracht ziehen. Über 100 MB ist Streaming Pflicht, es sei denn, Sie schauen gerne dabei zu, wie Ihrem Server der Speicher ausgeht.

XML vs JSON: Eine Kurzreferenz

Eine kurze Geschichte von XML

XML wurde im Februar 1998 als W3C-Empfehlung veröffentlicht. Es wurde als vereinfachte Untermenge von SGML (Standard Generalized Markup Language) entworfen, das seit den 1980er Jahren existierte, aber notorisch komplex war. Das Ziel war, ein Format zu schaffen, das sowohl menschenlesbar als auch maschinenauswertbar war, streng genug, um Mehrdeutigkeiten zu vermeiden, und flexibel genug für jede Domäne. Im ersten Jahrzehnt der 2000er war XML *das* Datenaustauschformat. SOAP-Webservices, RSS-Feeds, Atom-Feeds, XHTML — alles war XML. Dann kam JSON und übernahm den Web-API-Bereich, aber XML behielt jede Domäne, in der seine einzigartigen Features (Namensräume, Schemas, Transformationen) tatsächlich wichtig sind.

Der moderne XML-Entwickler

Die meisten Entwickler arbeiten heute in hybriden Umgebungen. Sie verwenden JSON für Web-APIs und Echtzeit-Kommunikation und XML für Dokumentenverarbeitung, Enterprise-Integration und regulatorische Compliance. Beide Formate zu kennen — und zu wissen, wann man welches einsetzt — ist eine wirklich wertvolle Fähigkeit.

XML-Sicherheit: XXE und andere Fallstricke

Wenn es eine Sache an XML gibt, die Sicherheitsingenieure nachts wach hält, dann ist es XXE — XML External Entity Angriffe. Und ehrlich gesagt, sollte es Sie auch beunruhigen. XXE steht aus gutem Grund auf der OWASP Top 10-Liste, und es erwischt auch 2026 noch Entwickler unvorbereitet.

So funktioniert XXE: XML erlaubt es Ihnen, „Entities" zu definieren — im Grunde Variablen — in der Document Type Declaration (DTD). Eine *externe* Entity kann auf eine URL oder einen Dateipfad auf dem Server verweisen. Wenn der Parser so konfiguriert ist, dass er externe Entities auflöst (viele sind das standardmäßig), kann ein Angreifer XML erstellen, das beliebige Dateien von Ihrem Server liest:

Wenn der Parser das verarbeitet, ersetzt er &xxe; durch den Inhalt von /etc/passwd. Einfach so liest ein Angreifer sensible Dateien von Ihrem System. Bei fortgeschritteneren Angriffen kann er sogar ausgehende HTTP-Anfragen von Ihrem Server machen (Server-Side Request Forgery) oder einen Denial-of-Service verursachen mit dem berüchtigten „Billion Laughs"-Angriff — einer rekursiven Entity-Expansion, die den gesamten verfügbaren Speicher verbraucht.

Die Lösung ist einfach: Deaktivieren Sie die Verarbeitung externer Entities. So geht es in zwei beliebten Sprachen:

Neben XXE achten Sie auf XML-Injection — wenn Benutzereingaben ohne ordentliches Escaping in XML eingefügt werden. Es ist das XML-Äquivalent von SQL-Injection. Verwenden Sie immer eine ordentliche XML-Builder-Bibliothek statt String-Konkatenation (was ich bereits im Abschnitt über häufige Fehler erwähnt habe, aber es ist es wert, wiederholt zu werden, weil es *so* wichtig ist).

Die goldene Regel: Parsen Sie niemals nicht vertrauenswürdiges XML mit Standard-Parser-Einstellungen. Deaktivieren Sie immer explizit die Auflösung externer Entities, DTD-Verarbeitung und XInclude-Verarbeitung. Behandeln Sie XML aus der Außenwelt mit demselben Misstrauen, mit dem Sie Benutzereingaben in einer SQL-Abfrage behandeln würden.

XPath: XML abfragen wie ein Profi

Wenn Sie regelmäßig mit XML arbeiten und kein XPath verwenden, machen Sie es sich unnötig schwer. XPath ist eine Abfragesprache, die speziell für die Navigation in XML-Dokumenten entwickelt wurde, und sie ist unglaublich mächtig, sobald man den Dreh raus hat.

Denken Sie an XPath wie CSS-Selektoren, aber für XML. Statt das DOM manuell mit verschachtelten Schleifen zu durchlaufen, schreiben Sie einen prägnanten Ausdruck, der genau die gewünschten Knoten auswählt. Hier sind einige praktische Beispiele:

So verwenden Sie XPath in JavaScript und Python — den beiden Sprachen, nach denen die meisten Entwickler greifen:

Eine Sache, die erwähnenswert ist: JSON hat keine eingebaute Abfragesprache. Das nächste Äquivalent ist jq, das fantastisch ist, aber ein externes Tool und kein standardisierter Teil des Formats. XPath ist in das XML-Ökosystem integriert — von Browsern nativ unterstützt, in praktisch jeder Programmiersprache verfügbar und vom W3C standardisiert. Es ist einer der echten Wettbewerbsvorteile von XML.

XPath bildet auch die Grundlage für XSLT (das Knoten zur Transformation auswählt) und XQuery (eine vollständige Abfragesprache für XML-Datenbanken). Sobald Sie XPath gelernt haben, haben Sie eine ganze Familie von XML-Technologien freigeschaltet.

XML in branchenspezifischen Standards

Ich habe vorhin Bank- und Gesundheitswesen erwähnt, aber XMLs Reichweite in branchenspezifische Standards geht viel tiefer. Hier ist ein Rundgang durch Domänen, in denen XML nicht nur verwendet wird — es ist *vorgeschrieben*:

Recht: Die Rechtsbranche verlässt sich stark auf XML für Gerichtseinreichungen und Fallverwaltung. LegalXML, entwickelt von OASIS, standardisiert elektronische Gerichtseinreichung, Rechtszitate und Fall-Metadaten. In den USA schreiben viele staatliche Gerichtssysteme XML-basierte E-Filing-Formate vor. Wenn Sie Legal Tech bauen, bauen Sie auf XML.

Verlagswesen: Hier ist eine Überraschung — jedes EPUB-E-Book, das Sie je gelesen haben, basiert auf XML. EPUB-Dateien sind ZIP-Archive mit XHTML-Inhaltsdateien (XML), einem OPF-Paketdeskriptor (XML) und einem Navigationsdokument (XML). DocBook, ein weiteres XML-Format, ist seit den 1990ern der Standard für technische Dokumentation. O'Reilly Media hat bekanntlich jahrelang DocBook verwendet, um ihre Bücher in mehreren Ausgabeformaten aus einer einzigen XML-Quelle zu produzieren.

Wissenschaft und Mathematik: MathML ist der W3C-Standard für die Darstellung mathematischer Notation in XML. Es wird von allen modernen Browsern unterstützt und ist unverzichtbar für wissenschaftliche Veröffentlichungen im Web. Dann gibt es Chemical Markup Language (CML) für Molekülstrukturen, Astronomical Markup Language für Sterndaten und Dutzende anderer wissenschaftlicher XML-Vokabulare. Wenn Präzision und eindeutige Datendarstellung wichtig sind — und in der Wissenschaft sind sie es immer — liefert XML.

Regierung und Beschaffung: Universal Business Language (UBL) ist ein OASIS-Standard, der von Regierungen weltweit für Beschaffung, Rechnungsstellung und Supply-Chain-Management verwendet wird. Die E-Invoicing-Richtlinie der Europäischen Union schreibt im Wesentlichen UBL-basiertes XML für Business-to-Government-Rechnungen vor. Wenn Sie an europäische Regierungen verkaufen, senden Sie XML-Rechnungen.

Luftfahrt: Das Aeronautical Information Exchange Model (AIXM) definiert XML-Schemas für Luftfahrtdaten — Flughäfen, Lufträume, Navigationshilfen, Verfahren. Jedes Flugmanagementsystem, jede Flugsicherungsaktualisierung, jedes NOTAM (Notice to Airmen) berührt AIXM-Daten. Dies ist eine Domäne, in der „lasst uns einfach auf JSON umsteigen" kein Gespräch ist, das irgendjemand führt, weil die Sicherheitsimplikationen einer Formatmigration enorm wären.

Der rote Faden durch all diese Branchen? Sie haben XML gewählt, weil sie starke Validierung, Namensräume zum Kombinieren von Vokabularen und ein Format brauchten, das sich über Jahrzehnte weiterentwickeln kann, ohne die Abwärtskompatibilität zu brechen. Diese Anforderungen haben sich nicht geändert.

SOAP vs REST: Warum XML-APIs noch existieren

Wenn Sie Ihre Karriere in den letzten zehn Jahren begonnen haben, denken Sie vielleicht, dass alle APIs REST mit JSON sind. Aber gehen Sie in eine große Bank, Versicherung, ein Telekommunikationsunternehmen oder eine Behörde, und Sie werden SOAP-Webservices finden, die kritische Geschäftslogik verarbeiten. Und dafür gibt es tatsächlich gute Gründe.

SOAP (Simple Object Access Protocol) ist ein XML-basiertes Nachrichtenprotokoll mit einigen Features, die REST+JSON out of the box einfach nicht bietet:

Starke Verträge über WSDL: Eine WSDL-Datei (Web Services Description Language) beschreibt *alles* über einen SOAP-Service — Operationen, Eingabe-/Ausgabe-Nachrichtenstrukturen, Datentypen, Endpunkte. Sie können Client-Code aus einer WSDL in Java, C#, Python oder praktisch jeder Enterprise-Sprache automatisch generieren. REST-APIs haben OpenAPI/Swagger, aber die Nutzung ist freiwillig. Bei SOAP ist der Vertrag der Service.

Eingebaute Fehlerbehandlung: SOAP hat ein standardisiertes Fault-Element mit Fehlercodes, Fehlerstrings und Detail-Elementen. Jeder SOAP-Client weiß genau, wie er Fehler parsen muss. REST-APIs? Jede API erfindet ihr eigenes Fehlerformat.

WS-Security: SOAP hat einen umfassenden Sicherheitsstandard, der Verschlüsselung und Signierung auf Nachrichtenebene unterstützt — nicht nur auf Transportebene (TLS). Das bedeutet, eine SOAP-Nachricht kann über Zwischenserver geleitet werden und trotzdem Ende-zu-Ende verschlüsselt bleiben. Das ist in der Finanzbranche sehr wichtig, wo Nachrichten über mehrere Systeme geroutet werden.

Transaktionen und Zuverlässigkeit: WS-AtomicTransaction und WS-ReliableMessaging bieten verteilte Transaktionsunterstützung und garantierte Zustellung. Das sind schwierige Probleme, die REST dem Anwendungsentwickler überlässt.

Allerdings hat SOAP echte Nachteile: Die Nachrichten sind ausführlich, die Lernkurve ist steil, Debugging ist mühsam, und der XML-Overhead macht es langsamer als JSON für einfache CRUD-Operationen. Für neue Web-APIs und Microservices ist REST+JSON fast immer die richtige Wahl. Aber für komplexe Enterprise-Integrationen — besonders in regulierten Branchen — bleiben SOAPs eingebaute Vertragsdurchsetzung und Sicherheitsfeatures wirklich wertvoll.

Migration von XML zu JSON: Ein praktischer Leitfaden

Irgendwann in Ihrer Karriere wird jemand Sie bitten, ein XML-basiertes System auf JSON zu migrieren. Bevor Sie „klar, einfach" sagen, lassen Sie mich Ihnen die Fallstricke zeigen, die jeden überraschen.

Attributverlust: XML-Elemente können sowohl Attribute als auch Kind-Elemente haben. JSON-Objekte haben nur Properties. Wenn Sie Dune konvertieren, wohin kommt id? Wohin kommt format? Wohin kommt der Textinhalt? Gängige Konventionen verwenden @-Präfixe für Attribute und #text für Textinhalt, aber es gibt keinen universellen Standard — und was auch immer Sie wählen, das andere System muss Ihre Konvention verstehen.

Typumwandlung: XML ist von Natur aus textbasiert. Der String "42" in XML könnte ein Integer, ein Float, ein String oder eine Postleitzahl sein. JSON hat unterschiedliche Typen. Bei der Migration brauchen Sie explizite Typ-Mapping-Regeln, sonst landen Sie mit Strings, wo Sie Zahlen wollten (oder schlimmer, mit Zahlen, wo Sie Strings wollten — auf Wiedersehen führende Nullen in Postleitzahlen).

Array-Mehrdeutigkeit: Diese ist besonders tückisch. In XML ist ein Element mit einem Kind ein einzelnes Element. Hat es mehrere Kinder mit demselben Namen, sind sie natürlich eine Sammlung. Aber JSON muss im Voraus wissen, ob etwas ein Array oder ein einzelner Wert ist. Betrachten Sie: Widget — ist item ein String oder ein Ein-Element-Array? Wenn eine andere Bestellung drei Items hat, ändert sich die Struktur. Ihr JSON-Konsument muss beide Fälle handhaben.

Schritte für eine erfolgreiche Migration:

• Schritt 1: Inventarisieren Sie alle XML-Schemas und dokumentieren Sie genau, welche Features Sie verwenden (Namensräume, Attribute, gemischter Inhalt, CDATA-Abschnitte, Verarbeitungsanweisungen).
• Schritt 2: Entwerfen Sie zuerst Ihr JSON-Schema und entscheiden Sie explizit, wie Attribute, gemischter Inhalt und Arrays behandelt werden. Dokumentieren Sie jede Entscheidung.
• Schritt 3: Bauen Sie eine Konvertierungsschicht (kein Big-Bang-Rewrite). Betreiben Sie beide Formate parallel und vergleichen Sie die Ausgaben.
• Schritt 4: Migrieren Sie Konsumenten nacheinander und halten Sie die XML-Endpunkte am Leben, bis alle umgestellt haben.
• Schritt 5: Betreiben Sie Parallelsysteme für mindestens einen vollständigen Geschäftszyklus (Monat, Quartal oder Jahr, je nach Domäne), bevor Sie XML stilllegen.

Wann Sie NICHT migrieren sollten: Wenn Ihr XML starke Namensraum-Mischung, XSLT-Transformationen oder XPath-basierte Geschäftsregeln verwendet, können die Migrationskosten den Nutzen überwiegen. Auch wenn Ihr XML durch einen regulatorischen Standard vorgeschrieben ist (HL7, ISO 20022, UBL), werden Sie XML in jedem Fall pflegen — JSON hinzuzufügen bedeutet nur ein zweites Format zu unterstützen.

XML-Tools, die jeder Entwickler kennen sollte

Die Arbeit mit XML muss nicht schmerzhaft sein, wenn Sie die richtigen Werkzeuge zur Hand haben. Hier sind die, auf die ich mich verlasse:

xmllint: Wird mit libxml2 ausgeliefert und ist wahrscheinlich schon auf Ihrem System. Es validiert XML gegen Schemas, formatiert (Pretty-Print) XML und wertet XPath-Ausdrücke aus — alles von der Kommandozeile. Es ist das curl der XML-Welt: einfach, schnell und überall.

Saxon: Der Goldstandard für XSLT- und XQuery-Verarbeitung, entwickelt von Michael Kay (der buchstäblich die XSLT 2.0- und 3.0-Spezifikationen herausgegeben hat). Wenn Sie ernsthafte XSLT-Transformationen machen, ist Saxon das Richtige. Die Open-Source Home Edition unterstützt XSLT 3.0 und XPath 3.1.

XMLSpy (Altova): Eine kommerzielle XML-IDE, die in Unternehmen beliebt ist. Sie hat visuelle Schema-Editoren, XSLT-Debugger und Datenbankintegration. Sie ist teuer, aber leistungsstark — besonders nützlich bei der Arbeit mit riesigen XSD-Schemas, die unpraktisch per Hand zu bearbeiten sind.

oXygen XML Editor: Mein persönlicher Favorit für XML-intensive Arbeit. Er unterstützt XSLT-Debugging mit Schritt-für-Schritt-Ausführung, XPath-Auswertung, schemabasierte Bearbeitung mit Autovervollständigung und hat ausgezeichnete DITA- und DocBook-Unterstützung. Wenn Sie regelmäßig XSLT schreiben, hat sich oXygen in einer Woche amortisiert.

xmlstarlet: Ein Kommandozeilen-XML-Toolkit, mit dem Sie XML direkt im Terminal abfragen, bearbeiten, validieren und transformieren können. Denken Sie daran wie sed und awk, aber für XML. Es ist perfekt für Shell-Skripte und CI/CD-Pipelines, in denen Sie Werte aus XML-Konfigurationsdateien extrahieren oder XML im Handumdrehen ändern müssen.

Visual Studio Code mit XML-Erweiterungen: Wenn Sie bereits in VS Code arbeiten, bietet die „XML"-Erweiterung von Red Hat Schema-Validierung, Autovervollständigung und Formatierung. Kombiniert mit der „XSLT/XPath"-Erweiterung ist es ein überraschend leistungsfähiges kostenloses Setup für gelegentliche XML-Arbeit.

Probieren Sie es selbst aus

Müssen Sie die beiden Welten verbinden? Unser XML-zu-JSON-Konverter übernimmt die Transformation unter Beibehaltung von Datenstruktur und Typen. Wenn Sie XML debuggen, macht der XML Formatter selbst das hässlichste XML lesbar. Und bevor Sie XML in die Produktion deployen, lassen Sie es durch den XML Validator laufen, um strukturelle Probleme frühzeitig zu erkennen.