Die Auszeichnungssprache Extensible Markup Language (XML)

https://bildung.social/@oerinformatik/111959976268780082

https://oer-informatik.de/xml-einstieg

XML, Auszeichnungssprache, Wohlgeformtheit, Gültigkeit, Wurzelelement, Prolog, CDATA, Entities, W3C, Datenaustausch

tl/dr; (ca. 18 min Lesezeit): Die Extensible Markup Language (XML) wird häufig zur Speicherung und zum Austausch hierarchischer Daten genutzt. Der allgemeine Aufbau von XML und das Hauptmerkmal - die Wohlgeformtheit - wird im Artikel beschrieben, ebenso typische Fehler, an denen die Wohlgeformtheit scheitert, der Unterschied zur Gültigkeit und die Vor- und Nachteile gegenüber CSV und binären Formaten. Dieser Artikel ist der erste Teil einer Artikelserie zu XML [AI-Assisted]. (Zuletzt geändert am 27.10.2026)

Dieser Artikel ist Bestandteil einer Serie zu den XML-Grundlagen:

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.

Nach Durchlesen des Artikels kann ich…

  • … Anwendungsfälle und Alleinstellungsmerkmale des Datenformats XML benennen,

  • … Merkmale von XML beschreiben und Vor- und Nachteile gegenüber CSV, JSON und binären Formaten wie PDF nennen,

  • … tabellarische Daten als XML-Dokument darstellen,

  • … die Kriterien nennen und anwenden, die eine XML-Datei erfüllen muss, um wohlgeformt zu sein,

  • … in einem XML-Dokument Verstöße gegen die Wohlgeformtheit finden und beschreiben,

  • … den Unterschied zwischen einer wohlgeformten und validen XML-Datei erklären,

  • … verschiedene Möglichkeiten benennen, mithilfe derer ich Zeichen in XML maskieren kann,

  • … und den Unterschied und die Gemeinsamkeiten zwischen HTML und XML benennen.

Wofür wird XML verwendet? Anwendungsfälle und Beispiele

Die Auszeichnungssprache XML dient zur Speicherung hierarchischer Daten, deren Struktur (und ggf. auch Datenformat) validierbar sein und deklarativ beschrieben werden sollen.

Die XML erinnert durch ihren Aufbau mit Tags (von spitzen Klammern umschlossene Bereiche) stark an die Internet-Auszeichnungssprache HTML. Tatsächlich stammen beide von der Standard Generalized Markup Language (SGML) ab, die aber selbst heute keine große Rolle mehr spielt und weitgehend unbekannt ist.

Sowohl XML als auch HTML erben von der SGML. XHTML ist wiederum eine Implementierung der XML mit den Elementen von HTML

Aus der gemeinsamen Herkunft ergeben sich die Gemeinsamkeiten: Beide nutzen dieselbe Tag-Syntax mit Start- und Endtags, Attribute als Name-Wert-Paare und Entities wie &lt; oder &amp;. Die Unterschiede liegen im Zweck: HTML hat ein festes Vokabular (<p>, <table>, <a> …), das Browser zur Darstellung von Webseiten kennen. In XML legst Du die Element- und Attributnamen selbst fest, um beliebige Daten zu beschreiben. Außerdem sind HTML-Parser fehlertolerant und zeigen auch fehlerhaftes Markup irgendwie an, während ein XML-Parser beim ersten Verstoß gegen die Wohlgeformtheit abbricht.

XML-Dokumente zeichnen sich dadurch aus, dass

  • Daten hierarchisch in einer Baumstruktur abgelegt werden,

  • die grundlegende Syntax immer gewährleistet ist, wenn das XML-Dokument den Regeln der Wohlgeformtheit entspricht,

  • die Struktur der Daten festlegbar und überprüfbar (validierbar) ist (mit Document Type Definitions oder Schema),

  • der Inhalt der Daten festlegbar und überprüfbar (validierbar) ist (mit Schema),

  • das Format beliebig erweiterbar ist und

  • es sich um einen weitverbreiteten Standard des W3C handelt.

Beispiele für XML-Dateien

XML-Dateien begegnen uns in der Praxis an sehr unterschiedlichen Stellen:

  • Die gängigen Office-Dokumente sind gezippte XML-Dateien: Das gilt sowohl für das OpenXML-Format von Microsoft (*.docx/*.xlsx) als auch für das OpenDocumentFormat, wie es z.B. LibreOffice nutzt (*.odt/*.ods). (Wer es nicht glaubt: einfach mal ein Word-Dokument entzippen und die entpackten Dateien im Editor öffnen).

  • Die Beschreibung von grafischen Benutzeroberflächen (GUI) wird häufig als XML-Struktur abgelegt (XAML bei C#/WPF, FXML bei JavaFX, XHTML als XML-Variante für Websites).

  • RSS-Feeds, mit denen wir Nachrichten, Podcasts usw. folgen können, sind als XML aufgebaut (z.B. ist der Feed dieser Seite hier erreichbar; den XML-Quelltext zeigt der Browser mit Strg+U).

  • XML wird zur Speicherung der Daten von Outdoor-Apps und als Konfigurationsdatei genutzt (beispielsweise die pom.xml des Build-Tools Maven).

Warum wird nicht einfach JSON, YAML oder CSV genutzt? Was ist das Alleinstellungsmerkmal von XML?

Ohne einen tieferen Blick in die Bestandteile von XML geworfen zu haben, fallen zunächst zwei Unterschiede auf:

  • Im Vergleich zu CSV-Dateien: XML-Dokumente sind gut geeignet, um ein hierarchisches Datenmodell (eine Baumstruktur) abzubilden. CSV-Dateien eignen sich für relationale Modelle (also nicht für Baumstrukturen, sondern für Daten, die sich tabellarisch erfassen lassen).

  • JSON und YAML sind zwar geeignet, um hierarchische Daten in variablen Baumstrukturen abzubilden, bieten aber von sich aus keine Möglichkeit, die Datenstruktur und den Dateninhalt innerhalb des Datenformats zu beschreiben und über einen allgemeinen Parser zu validieren. Dafür braucht es Zusatzstandards wie JSON Schema, die nicht Teil von JSON selbst sind, oder die Prüfung wird individuell programmiert. Bei XML sind DTD (Teil des XML-Standards) und XML Schema (ebenfalls W3C) seit Langem etabliert und werden von nahezu allen Bibliotheken unterstützt.

  • Im Vergleich zu binären Formaten (z. B. PDF oder Datenbankdateien): XML ist reiner Text. Es lässt sich mit jedem Texteditor öffnen, ist für Menschen lesbar und zugleich maschinell einfach zu verarbeiten, ist unabhängig von Plattform und Programm und lässt sich gut versionieren und vergleichen. Ein PDF zeigt dagegen vor allem, wie etwas aussieht: Welche Zahl auf der Seite die Rechnungssumme ist, kann ein Programm nicht sicher erkennen.

  • Der Preis dafür: XML ist geschwätzig. Jeder Wert steht zwischen Start- und Endtag, und die Namen wiederholen sich in jedem Datensatz. Gegenüber CSV entsteht dadurch ein Vielfaches an Datenmenge (Overhead), was bei sehr vielen kleinen Datensätzen (z. B. Messwerten, die per Funk übertragen werden) oder großen Datenbeständen ins Gewicht fällt. CSV ist kompakter, kennt aber weder Hierarchie noch Datentypen noch ein standardisiertes Schema.

Wie dieselben Daten in beiden Formaten aussehen, zeigt ein kleines Beispiel – zwei Bücher einer Schulbibliothek, zuerst als CSV:

signatur;titel;jahr;ausgeliehen
INF-0815;XML kompakt;2024;ja
INF-0816;Datenbanken verstehen;2025;nein

Und als XML:

<?xml version="1.0" encoding="UTF-8"?>
<bibliothek schule="Berufskolleg">
    <buch signatur="INF-0815">
        <titel>XML kompakt</titel>
        <jahr>2024</jahr>
        <ausgeliehen>ja</ausgeliehen>
    </buch>
    <buch signatur="INF-0816">
        <titel>Datenbanken verstehen</titel>
        <jahr>2025</jahr>
        <ausgeliehen>nein</ausgeliehen>
    </buch>
</bibliothek>

Typisch ist: Eine Tabellenzeile wird zu einem Element (hier buch), die Spalten werden zu Kindelementen oder Attributen, und alles steckt in genau einem Wurzelelement. Angaben, die für alle Datensätze gleich sind (hier die Schule), legt XML einmal weiter oben im Baum ab – in CSV müssten sie in jeder Zeile wiederholt werden.

XML-Dokumente verfügen über zwei Qualitätsmerkmale:

  • Sie müssen wohlgeformt (well formed) sein. Wohlgeformt ist die Bezeichnung dafür, dass ein Dokument den allgemeinen XML-Regeln entspricht. Nur wohlgeformte XML-Dateien werden von Parsern interpretiert. Die Regeln folgen in den kommenden Absätzen.

  • Darüber hinaus können wohlgeformte XML-Dateien in Struktur und Inhalt einem definierten Aufbau entsprechen: Man spricht dann von gültigen (valid) XML-Dokumenten. Valide können XML-Dateien gegen ein XML-Schema (XSD) oder gegen eine Document Type Definition (DTD) sein. Die Erklärung dieser beiden Eigenschaften folgt in weiteren Artikeln.

Bestandteile eines XML-Dokuments

Wir betrachten als Beispiel eine vereinfachte GPX-Datei einer Outdoor-App:

Beispiel einer GPX-XML-Datei, in der Prolog, Wurzelelement, Start- und Endtags sowie ein leeres Element gekennzeichnet sind.

Kernbestandteil von XML-Dokumenten sind Elemente:

  • Elemente werden in Tags eingefasst. Es gibt öffnende Tags (Starttag: <name>), bei denen der Name direkt nach der spitzen Klammer steht, und schließende Tags (Endtag: </name>), bei denen ein Slash dem case-sensitive-Tagnamen des zugehörigen Starttags vorangestellt wird. Zwischen diesen beiden Tags steht der Elementinhalt (Content).

  • Elemente ohne Inhalt können in Kurzschreibweise mithilfe des empty Element Tags abgekürzt werden: hier werden Starttag und Endtag in einem einzigen Tag zusammengefasst, das mit dem Slash vor der schließenden spitzen Klammer endet: (statt <link href="https://www.komoot.de"></link> kann man kurz schreiben: <link href="https://www.komoot.de" />)

  • Das erste sich öffnende Element nennt sich Wurzelelement (Root-Element oder Document Element). Im obigen Beispiel ist das Wurzelelement <gpx ...>...</gpx>. Es darf auf der Ebene des Root Elements kein zweites Element geben.

  • Neben Elementinhalt (content, also Text oder weitere Elemente zwischen öffnendem und schließendem Tag) können Elemente auch Daten in Attributen speichern. Diese werden als Key/Value-Paare durch Gleichheitszeichen getrennt, wobei die Values in einfache oder doppelte Anführungszeichen eingeschlossen werden. Innerhalb eines Tags darf jeder Key nur einmal vorkommen und die Values dürfen keine öffnende spitze Klammer < (und kein unmaskiertes &) enthalten. Im obigen Beispiel finden sich Attribute in dem Element <trkpt lat="52.022650" lon="8.549855" />.

Allgemeiner Aufbau rund um das Wurzelelement

Ein XML-Dokument besteht aus dem Prolog und dem Wurzelelement.

Der Prolog ist optional. Er beginnt mit der ebenso optionalen XML-Deklaration - im obigen Beispiel <?xml version='1.0' encoding='UTF-8' standalone='yes'?>. Falls eine XML-Deklaration enthalten ist, muss diese direkt am Anfang stehen.

Weiterhin können im Prolog die Dokumenttyp-Deklaration (<!DOCTYPE …>, sie bindet eine DTD ein, siehe Teil 2), Verarbeitungshinweise (Processing Instructions) stehen sowie - wie überall in XML-Dokumenten - Whitespaces und Kommentare.

Kommentare werden zwischen <!-- und --> eingeschlossen (wobei das letzte Zeichen des Kommentarinhalts kein - sein darf): <!-- gültiger Kommentar --> und <!---ungültiger Kommentar--->. Innerhalb eines Kommentars darf kein doppelter Bindestrich vorkommen: <!--ungültiger--Kommentar-->

Verarbeitungshinweise (Processing Instructions) werden zwischen <? und ?> eingeschlossen. Sie richten sich an verarbeitende Programme; so bindet z. B. <?xml-stylesheet type="text/xsl" href="anzeige.xsl"?> ein Stylesheet für die Anzeige ein. Eine Document Type Definition (DTD) wird dagegen nicht per Verarbeitungshinweis, sondern über die Dokumenttyp-Deklaration <!DOCTYPE …> eingebunden.

Auf den Prolog folgt das eine Wurzelelement und dessen Elementinhalt. Innerhalb des Wurzelelements dürfen auch Kommentare und Whitespaces genutzt werden.

Optional dürfen nach dem Wurzelelement nur noch Kommentare, Verarbeitungshinweise oder Whitespaces folgen.

Die Regeln der Wohlgeformtheit (well-formed constraints)

Ein XML-Dokument ist wohlgeformt (well-formed), wenn (kursiv in Klammer die Bezeichnungen im Standard):

  • es genau ein Root-Element (auch document element genannt) gibt,

  • vor dem Root-Element optional der Prolog, nach dem Root-Element höchstens Kommentare oder Verarbeitungshinweise stehen,

  • alle nicht leeren Elemente mit einem Endtag geschlossen werden, das denselben case-sensitiven Namen trägt wie das Starttag (Element Type Match),

  • alle Elemente innerhalb derselben Elemente geschlossen werden, innerhalb derer sie geöffnet werden (also in umgekehrter Reihenfolge schließen wie öffnen),

  • enthaltene Texte sich aus Unicode-Zeichen zusammensetzen (bis auf wenige nicht erlaubte Steuerzeichen, siehe link) (Legal Character),

  • enthaltene Element- und Attributnamen keine Leerzeichen enthalten und nicht mit Punkt, Zahlen und Bindestrich beginnen (sowie weiteren, weniger gebräuchlichen Zeichen wie dem Malpunkt #xB7 und diakritischen Zeichen #x0300-#x036F und #x203F-#x2040) – Namen, die mit xml in beliebiger Groß-/Kleinschreibung beginnen, sind für künftige Standards reserviert und sollten vermieden werden,

  • Attributnamen innerhalb eines Tags nur einmal vorkommen (Unique Att Spec),

  • Attributwerte in einfachen oder doppelten Anführungszeichen eingeschlossen sind und kein < enthalten (No < in Attribute Values),

  • die Zeichen < und & im Text nur maskiert vorkommen (&lt;, &amp;, siehe unten) – ein einzelnes & wie in „Müller & Söhne“ macht das Dokument nicht wohlgeformt,

  • Attributwerte keine externen Entitäten referenzieren (No External Entity References),

  • Document-Type-Definition (falls vorhanden) sich auch an die Regeln der Wohlgeformtheit halten (PEs in Internal Subset, External Subset, PE Between Declarations),

  • alle referenzierten Entitäten auch wohlgeformt sind (hierzu im nächsten Artikel mehr, Entity Declared, Parsed Entity, No Recursion, In DTD).

Alle Parser brechen die Verarbeitung von nicht wohlgeformten XML-Dateien ab. Auch Browser haben in der Regel einen integrierten XML-Parser, mit dem man ein wohlgeformtes XML-Dokument betrachten und bei einem nicht wohlgeformten XML-Dokument eine Fehlermeldung erhält.

Typische Fehler: Woran scheitert die Wohlgeformtheit?

Die meisten Fehler entstehen, wenn XML von Hand geschrieben oder im Programm per Zeichenkettenverkettung „zusammengebaut“ wird. Diese Fehlerbilder solltest Du auf einen Blick erkennen:

Typische Verstöße gegen die Wohlgeformtheit
Fehlerbild Beispiel Korrekt
Endtag fehlt <name>Runde am Obersee … </trk> <name>Runde am Obersee</name>
Endtag anders geschrieben (Groß-/Kleinschreibung) <ele>110</ELE> <ele>110</ele>
Tag unvollständig <name>Obersee</name <name>Obersee</name>
Elemente überlappen sich <trk><name>Obersee</trk></name> <trk><name>Obersee</name></trk>
Attributwert ohne Anführungszeichen <gpx version=1.1> <gpx version="1.1">
Attribut doppelt im selben Tag <trkpt lat="52.05" lat="52.06"/> jedes Attribut nur einmal
zweites Wurzelelement <gpx>…</gpx><gpx>…</gpx> beide Inhalte in ein gemeinsames Wurzelelement
unmaskiertes & oder < im Text <name>Kaffee & Kuchen</name> <name>Kaffee &amp; Kuchen</name>
unzulässiger Name <1punkt>, <mein punkt> <punkt1>, <mein_punkt>
XML-Deklaration nicht am Anfang Leerzeile oder Kommentar vor <?xml …?> Deklaration in die erste Zeile

Ein Parser behandelt jeden dieser Verstöße als fatalen Fehler: Er bricht beim ersten Fehler ab und meldet nur diesen. Erst wenn Du ihn behoben hast, bekommst Du den nächsten zu sehen. Die gemeldete Zeile ist dabei nicht immer die, in der der eigentliche Fehler steckt: Fehlt ein Endtag, merkt der Parser das erst, wenn ein Endtag kommt, das nicht zum offenen Element passt. Suche deshalb auch in den Zeilen davor.

Wohlgeformt ist nicht gleich gültig

Die Wohlgeformtheit lässt sich an jedem XML-Dokument ohne weitere Informationen prüfen – sie betrifft nur die allgemeine Syntax. Ob die richtigen Elemente in der richtigen Reihenfolge und Anzahl vorkommen, ob Pflichtangaben fehlen oder ob ein Wert den passenden Datentyp hat, sagt sie nicht. Das prüft erst die Gültigkeit (validity) gegen eine DTD oder ein XML Schema, die für einen bestimmten Dokumenttyp festlegen, was erlaubt ist (siehe Teil 2 und Teil 4). Ein gültiges Dokument ist immer auch wohlgeformt – umgekehrt gilt das nicht.

In der Praxis wird ein ausgetauschtes XML-Dokument deshalb in Stufen geprüft:

  1. wohlgeformt? – prüft jeder XML-Parser automatisch,

  2. gültig? – prüft ein validierender Parser gegen DTD oder XSD,

  3. fachlich richtig? – stimmen z. B. Summen, Datumsangaben oder Verweise? Das kann weder DTD noch XSD vollständig prüfen; dafür braucht es zusätzliche Regeln und Tests (siehe Teil 4).

Wo können in XML überall Nutzdaten gespeichert werden?

In XML-Dokumenten können Daten auf unterschiedliche Weise an verschiedenen Stellen gespeichert werden:

  • als Elementinhalt zwischen Start- und Endtag,

  • als Attributwert zwischen den einfachen oder doppelten Anführungszeichen,

  • als Elementname,

  • als Attributname und

  • in der Struktur (Reihenfolge) der Elemente.

(Zusätzlich können Informationen natürlich auch in Kommentaren stehen, wenngleich das ein denkbar schlechter Ort ist.)

Ungültige Zeichen, CDATA und Entities

Die Daten können nahezu den ganzen Unicode-Zeichenumfang nutzen (bis auf wenige nicht erlaubte Steuerzeichen, siehe Abschnitt „Characters“ im XML-Standard) und als normale Zeichenketten gespeichert werden. Jedoch werden beispielsweise die spitzen Klammern als XML-Bestandteil interpretiert. Es ist daher nicht einfach so möglich, XML- oder HTML-Tags als Content in XML-Dateien zu speichern.

Ein Weg, Daten zu maskieren, damit sie nicht als XML-Markup interpretiert werden, stellen die CDATA-Blöcke dar, die mit <![CDATA[ eingeleitet und mit ]]> abgeschlossen werden. In ihnen darf alles enthalten sein, außer die Zeichenfolge ]]>. Wenn also in XML beispielsweise ein fett-geschriebener HTML-Textschnipsel gespeichert werden soll, so lautet der zugehörige CDATA-Abschnitt:

<![CDATA[ <b>bold</b> ]]>

XML bietet einige interne Entities, die genutzt werden können, Konflikte mit Zeichen besonderer Bedeutung zu verhindern:

  • &lt; repräsentiert das < (relevant bei mathematischen Vergleichen oder wenn Tags als Inhalt gespeichert werden sollen, z.B. &lt;b&gt;bold&lt;/b&gt;)

  • &gt; repräsentiert das > (relevant bei mathematischen Vergleichen oder wenn Tags als Inhalt gespeichert werden sollen, z.B. &lt;b&gt;bold&lt;/b&gt;)

  • &amp; repräsentiert das & (relevant in allen Zeichenketten, z.B. <text>Hinz&amp;Kunz</text> statt des nicht wohlgeformten <text>Hinz&Kunz</text>)

  • &apos; repräsentiert das ' (relevant in einfach angeführten Attributwerten, z.B: stringdelimiter='&apos;')

  • &quot; repräsentiert das " (relevant in doppelt angeführten Attributwerten, z.B. stringdelimiter="&quot;")

Auf die Möglichkeit, eigene Entities zu definieren, gehe ich im DTD-Artikel ein.

Zum Abschluss: Welcher Standard ist derzeit gültig?

Die derzeit aktuelle und meist genutzte Version des Standards heißt nach wie vor Version 1.0. Sie ist mittlerweile in der “Fifth Edition” verfügbar, die sich nur unwesentlich (v.a. im Umgang mit Unicode) von den vorigen Editionen unterscheidet. Sie findet sich hier (XML 1.0, Fifth Edition).

Es existiert parallel eine weniger verbreitete Version, irritierenderweise mit höherer Versionsnummer: XML 1.1 (link). In dieser wurden neue Wege beschritten, Unicode und Zeilenumbrüche einzubinden, die später auf anderem Weg in die oben genannte Fifth Edition eingeflossen sind. Für die allermeisten Anwendungsfälle ist XML 1.0 der Weg der Wahl. Wer mit besonderen Zeilenumbrüchen operieren muss (#x85, #x2028) oder Steuerzeichen wie #x1 als Zeichenreferenz in den Daten benötigt, der möge einen Blick auf die Unterschiede werfen, die hier konkreter beschrieben werden. Die erweiterten Zeichen für Element- und Attributnamen aus XML 1.1 gelten seit der Fifth Edition auch für XML 1.0.

Leitfragen

  1. Wofür wird XML eingesetzt, und welche Merkmale zeichnen das Format aus?

XML dient zur Speicherung und zum Austausch hierarchischer Daten, z. B. in Office-Dokumenten, GUI-Beschreibungen, RSS-Feeds oder Konfigurationsdateien. Kennzeichnend sind die Baumstruktur, die durch Wohlgeformtheit gesicherte Syntax, die per DTD oder Schema validierbare Struktur und Inhalte, die beliebige Erweiterbarkeit und die Standardisierung durch das W3C – siehe Abschnitt „Wofür wird XML verwendet? Anwendungsfälle und Beispiele“.

  1. Welche Vor- und Nachteile hat XML gegenüber CSV, JSON und binären Formaten wie PDF?

Anders als CSV bildet XML Hierarchien ab, und anders als JSON bringt es mit DTD und XML Schema etablierte Standards zur Validierung mit; gegenüber binären Formaten wie PDF ist es reiner, menschen- und maschinenlesbarer, plattformunabhängiger und gut versionierbarer Text. Nachteil ist die „Geschwätzigkeit“: Durch Start- und Endtags und wiederholte Namen entsteht gegenüber CSV ein Vielfaches an Datenmenge – siehe Abschnitt „Warum wird nicht einfach JSON, YAML oder CSV genutzt? Was ist das Alleinstellungsmerkmal von XML?“.

  1. Aus welchen Bestandteilen besteht ein XML-Dokument (Prolog, Wurzelelement, Elemente, Attribute, Kommentare)?

Ein XML-Dokument besteht aus dem optionalen Prolog (XML-Deklaration ganz am Anfang, ggf. <!DOCTYPE …>, Verarbeitungshinweise, Kommentare) und genau einem Wurzelelement mit seinem Inhalt. Elemente bestehen aus Start- und Endtag (oder einem empty element tag <x />) und können Attribute als Name-Wert-Paare in Anführungszeichen tragen; Kommentare stehen zwischen <!-- und --> – siehe Abschnitt „Kernbestandteil von XML-Dokumenten sind Elemente:“ und Abschnitt „Allgemeiner Aufbau rund um das Wurzelelement“.

  1. Welche Regeln muss ein Dokument einhalten, damit es wohlgeformt ist?

Wohlgeformt ist ein Dokument u. a., wenn es genau ein Wurzelelement hat, jedes nicht leere Element mit einem gleichnamigen Endtag (case-sensitive) geschlossen wird, Elemente sich nicht überlappen, Namen keine Leerzeichen enthalten und nicht mit Zahl, Punkt oder Bindestrich beginnen, jedes Attribut je Tag nur einmal vorkommt und in Anführungszeichen steht und < und & im Text nur maskiert vorkommen – siehe Abschnitt „Die Regeln der Wohlgeformtheit (well-formed constraints)“.

  1. Woran erkennst Du typische Wohlgeformtheitsfehler, und wie reagiert ein Parser darauf?

Typische Fehler sind fehlende oder anders geschriebene Endtags, unvollständige Tags, überlappende Elemente, Attributwerte ohne Anführungszeichen, doppelte Attribute, ein zweites Wurzelelement, unmaskiertes & oder <, unzulässige Namen und eine XML-Deklaration, die nicht am Anfang steht. Ein Parser behandelt jeden davon als fatalen Fehler, bricht beim ersten ab und meldet nur diesen – oft erst in einer späteren Zeile, deshalb suchst Du auch davor – siehe Abschnitt „Typische Fehler: Woran scheitert die Wohlgeformtheit?“.

  1. Worin unterscheiden sich „wohlgeformt“ und „gültig“?

Wohlgeformt heißt, dass ein Dokument die allgemeinen XML-Syntaxregeln einhält; das lässt sich ohne weitere Informationen prüfen. Gültig ist es erst, wenn es zusätzlich den Regeln einer DTD oder eines XML Schemas für einen bestimmten Dokumenttyp entspricht (richtige Elemente, Reihenfolge, Anzahl, Datentypen); jedes gültige Dokument ist wohlgeformt, aber nicht umgekehrt – siehe Abschnitt „Wohlgeformt ist nicht gleich gültig“.

  1. Wie maskierst Du Zeichen wie < und &?

Du nutzt die vordefinierten Entities &lt; für <, &amp; für &, &gt; für > sowie &apos; und &quot; für Anführungszeichen in Attributwerten. Größere Textstücke mit Markup kannst Du in einen CDATA-Block <![CDATA[ … ]]> einschließen, der alles außer der Zeichenfolge ]]> enthalten darf – siehe Abschnitt „Ungültige Zeichen, CDATA und Entities“.

  1. Was haben HTML und XML gemeinsam, und worin unterscheiden sie sich?

Beide stammen von der SGML ab und nutzen dieselbe Tag-Syntax, Attribute und Entities. HTML hat jedoch ein festes Vokabular zur Darstellung von Webseiten, während Du in XML die Elemente und Attribute selbst festlegst, um beliebige Daten zu beschreiben. HTML-Parser sind fehlertolerant, ein XML-Parser bricht beim ersten Wohlgeformtheitsfehler ab – siehe Abschnitt „Wofür wird XML verwendet? Anwendungsfälle und Beispiele“.


Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Die Auszeichnungssprache Extensible Markup Language (XML)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/xml-einstieg veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/datenformate/xml. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 27.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen: