XML-Grundlagen: Aufbau, Namespaces, DTD, XSLT und XPath

XML-Grundlagen: Aufbau, Namespaces, DTD, XSLT und XPath

Tech

XML gilt vielen als Technik der Nullerjahre, steckt aber in jeder Word-Datei, jeder Sitemap und seit 2025 in jeder deutschen E-Rechnung. Wer eine XRechnung prüfen, einen Feed reparieren oder eine Schnittstelle anbinden muss, kommt mit ein paar Grundregeln weit. Dieser Beitrag erklärt sie an einem durchgehenden Beispiel und sagt, wann JSON die bessere Wahl ist.

Von 1998 bis heute: XML 1.0 in der fünften Ausgabe

Das W3C verabschiedete die Extensible Markup Language (XML) 1.0 am 10. Februar 1998 als Recommendation. XML ist eine vereinfachte Teilmenge von SGML, der Metasprache, auf der auch HTML bis Version 4.01 aufbaute. Die bis heute gültige Fassung ist die fünfte Ausgabe vom 26. November 2008. Sie ist ausdrücklich keine neue XML-Version, sondern sammelt Korrekturen. Zu den Entwurfszielen der Spezifikation gehört übrigens der Satz, Knappheit des Markups sei von minimaler Bedeutung, was die Geschwätzigkeit vieler XML-Formate erklärt.

Wichtig für die Praxis: Jeder XML-Parser muss UTF-8 und UTF-16 verstehen. Wer eine andere Kodierung nutzt, muss sie in der XML-Deklaration angeben. Warum UTF-8 fast immer die richtige Wahl ist, erklärt der Beitrag zur Zeichenkodierung UTF-8.

Ein Beispieldokument Zeile für Zeile

<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='bestellung.xsl'?>
<!DOCTYPE bestellung [
  <!ELEMENT bestellung (kunde, position+)>
  <!ATTLIST bestellung nr CDATA #REQUIRED>
  <!ELEMENT kunde (#PCDATA)>
  <!ELEMENT position (artikel, menge)>
  <!ELEMENT artikel (#PCDATA)>
  <!ELEMENT menge (#PCDATA)>
]>
<bestellung nr='2026-0815'>
  <kunde>Müller &amp; Söhne GmbH</kunde>
  <position>
    <artikel>Druckerpapier A4</artikel>
    <menge>5</menge>
  </position>
  <position>
    <artikel>Toner schwarz</artikel>
    <menge>2</menge>
  </position>
</bestellung>
  • XML-Deklaration in der ersten Zeile: Version und Kodierung.
  • Verarbeitungsanweisung xml-stylesheet: verknüpft ein Stylesheet, hier XSLT.
  • DOCTYPE mit interner DTD: legt fest, welche Elemente in welcher Reihenfolge vorkommen dürfen.
  • Elemente wie position tragen Inhalt, Attribute wie nr beschreiben ein Element näher.
  • Das & in „Müller & Söhne“ muss als &amp; geschrieben werden.

Wohlgeformt und gültig sind zwei Stufen

Wohlgeformt ist ein Dokument, das die Grammatik von XML einhält: genau ein Wurzelelement, jedes Element geschlossen, korrekt verschachtelt, Attributwerte in Anführungszeichen, < und & im Text maskiert, Groß- und Kleinschreibung beachtet. Verstöße sind laut Spezifikation fatale Fehler, nach denen ein Parser die normale Verarbeitung abbrechen muss. Anders als ein Browser bei HTML repariert XML nichts stillschweigend.

Gültig (valid) ist ein wohlgeformtes Dokument, das zusätzlich eine Dokumenttyp-Deklaration hat und deren Regeln erfüllt. Das Beispiel oben ist beides. Fehlt kunde, bleibt es wohlgeformt, ist aber ungültig. Prüfen lässt sich das mit xmllint aus der Bibliothek libxml2:

xmllint --noout bestellung.xml          # nur Wohlgeformtheit
xmllint --valid --noout bestellung.xml  # zusätzlich gegen die DTD

DTDs sind die älteste Art, Regeln festzulegen. Sie kennen keine Datentypen: Dass menge eine Zahl sein soll, lässt sich damit nicht ausdrücken. Für Datenaustausch hat sich deshalb XML Schema durchgesetzt, das im Beitrag zu XML Schema (XSD) ausführlich behandelt wird.

Namespaces: wenn zwei Vokabulare aufeinandertreffen

Sobald ein Dokument Elemente aus verschiedenen Formaten mischt, drohen Namenskollisionen. Namespaces lösen das über eine URI, die mit xmlns deklariert wird. Die Regeln stehen in „Namespaces in XML 1.0“, aktuell in der dritten Ausgabe von 2009.

<katalog xmlns='https://example.com/ns/katalog'
         xmlns:preis='https://example.com/ns/preise'>
  <produkt id='p1'>
    <name>Toner schwarz</name>
    <preis:netto waehrung='EUR'>39.90</preis:netto>
  </produkt>
</katalog>

xmlns='…' setzt den Standard-Namespace für alle Elemente ohne Präfix, xmlns:preis='…' bindet ein Präfix. Die URI muss nicht abrufbar sein, sie dient nur als eindeutiger Name. Eine häufige Stolperfalle: Der Standard-Namespace gilt laut Spezifikation nicht für Attribute ohne Präfix. Und wer in XPath nach /katalog/produkt sucht, findet nichts, solange der Namespace nicht im Werkzeug registriert ist. Genau daran scheitern viele erste Versuche, eine XRechnung maschinell auszulesen.

XSLT und XPath: Daten umformen und abfragen

XPath ist die Abfragesprache für XML-Bäume. Ein paar Ausdrücke für das Beispieldokument:

XPath-AusdruckErgebnis
/bestellung/@nr2026-0815
//position[menge > 3]/artikelDruckerpapier A4
count(//position)2

XSLT nutzt XPath, um ein XML-Dokument in ein anderes Format zu übersetzen, etwa HTML. Das zum Beispiel passende Stylesheet:

<xsl:stylesheet version='1.0'
    xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
  <xsl:template match='/'>
    <ul>
      <xsl:for-each select='bestellung/position'>
        <li><xsl:value-of select='menge'/> x <xsl:value-of select='artikel'/></li>
      </xsl:for-each>
    </ul>
  </xsl:template>
</xsl:stylesheet>

Die aktuelle Version XSLT 3.0 ist seit dem 8. Juni 2017 W3C-Recommendation, Werkzeuge wie Saxon setzen sie um. Eine Warnung für alle, die XSLT direkt im Browser nutzen, etwa für hübsch formatierte Sitemaps oder Feeds per xml-stylesheet: Google entfernt XSLT aus Chrome. Laut Chrome-Entwicklerdokumentation funktioniert es ab Chrome 158 (geplant für den 17. November 2026) in der stabilen Version nicht mehr, Firefox und WebKit haben ähnliche Pläne signalisiert. Wer heute auf clientseitiges XSLT setzt, sollte die Transformation auf den Server oder in ein Build-Skript verlegen.

Wo XML heute steckt

EinsatzFormatHinweis
E-RechnungXRechnung, ZUGFeRDseit 2025 Empfangspflicht für Unternehmen in Deutschland
Sitemapssitemaps.org-ProtokollUTF-8 Pflicht, bis 50.000 URLs und 50 MB pro Datei
FeedsRSS 2.0, Atom (RFC 4287)Podcasts und Blogs
VektorgrafikSVGdirekt in HTML einbettbar
Office-DateienOffice Open XML (ECMA-376, ISO/IEC 29500), ODF.docx und .odt sind ZIP-Archive mit XML-Dateien

In Sitemaps zeigt sich die XML-Strenge im Alltag: Ein & in einer URL muss laut Protokoll als &amp; erscheinen, sonst ist die Datei nicht wohlgeformt. Wie Feeds aufgebaut sind, steht im Beitrag RSS-Feeds erklärt.

E-Rechnung: XRechnung und ZUGFeRD

Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland E-Rechnungen empfangen können, ein normales E-Mail-Postfach genügt dafür. Ausstellen müssen sie inländische Unternehmen nach Übergangsfristen spätestens ab 2028, Ausnahmen gelten etwa für Kleinbetragsrechnungen und Rechnungen an Privatkunden. Eine E-Rechnung ist ein strukturierter Datensatz nach der europäischen Norm EN 16931, ein reines PDF zählt nicht.

Die XRechnung ist reines XML in einer von zwei Syntaxen, UBL 2.1 oder UN/CEFACT CII. Betreut wird der Standard von der Koordinierungsstelle für IT-Standards (KoSIT). Gültig ist Stand Oktober 2026 die Version 3.0, laut KoSIT mindestens bis 31. Juli 2027. Eine vorläufige Spezifikation für Version 4.0 erschien im September 2026, die endgültige Fassung ist für Frühjahr 2027 angekündigt. ZUGFeRD ist ein hybrides Format: ein PDF/A-3 für das menschliche Auge, in das eine inhaltsgleiche XML-Datei auf Basis von CII eingebettet ist. Dieser Überblick ist keine Steuerberatung, verbindlich sind die Schreiben des Bundesfinanzministeriums.

XML oder JSON: eine klare Empfehlung

Für neue Web-APIs, Konfigurationsdateien und alles, was im Browser per JavaScript verarbeitet wird, ist JSON die bessere Wahl: kürzer, direkt als Objekt nutzbar, von jeder Sprache gelesen. XML lohnt sich dort, wo seine Stärken zählen:

  • Dokumente mit gemischtem Inhalt, also Text mit eingebetteter Auszeichnung wie in Büchern, Verträgen oder technischer Dokumentation.
  • Formate, die ein Standard vorschreibt: E-Rechnung, Office-Dateien, SVG, Sitemaps, Behördenschnittstellen.
  • Strenge Validierung mit ausgereiften Schemas und Namespaces, wenn viele Partner dieselben Daten austauschen.

Wer also eine eigene Schnittstelle baut, nimmt JSON. Wer ein bestehendes XML-Format bedienen muss, sollte es nicht in JSON nachbauen, sondern mit einem echten Parser und Schema-Validierung arbeiten, statt XML mit regulären Ausdrücken oder String-Verkettung zu erzeugen.

Quellen

Verwandte Beiträge