Eine Buchhaltungssoftware exportiert Rechnungsdaten als XML, ein Sitemap-Plugin erzeugt eine XML-Sitemap, eine DOCX-Datei enthält intern XML-Strukturen, ein Feed wird im XML-basierten Atom-Format bereitgestellt oder eine Schnittstelle verlangt ausdrücklich eine XML-Datei. In all diesen Fällen dient XML dazu, Daten so zu kennzeichnen und zu ordnen, dass eine Software ihre Struktur zuverlässig erkennen kann.
XML steht für Extensible Markup Language und ist eine Auszeichnungssprache, mit der strukturierte Daten in einer hierarchischen Form beschrieben werden können. Die Struktur entsteht durch benannte Elemente, öffnende und schließende Tags, Attribute, Textinhalte und deren Verschachtelung.
XML ist ein textbasiertes Format. Menschen können die Namen und die grundsätzliche Gliederung einer Datei meist direkt lesen; Programme können dieselbe Struktur mit einem XML-Parser systematisch verarbeiten. Lesbar bedeutet allerdings nicht automatisch selbsterklärend: Ob ein Feld verpflichtend ist, welche Einheit ein Wert besitzt oder welche Reihenfolge eine Schnittstelle erwartet, ergibt sich erst aus der Dokumentation oder einem Schema.
Im Vergleich zu JSON wirkt XML bei einer ähnlichen Datenabbildung häufig ausführlicher, weil Elementnamen in Start- und End-Tags wiederholt werden. Diese Ausführlichkeit ist keine bloße Altlast: XML unterstützt unter anderem Attribute, Namespaces, dokumentorientierte Inhalte sowie etablierte Schema- und Validierungsverfahren.
XML-Grundstruktur: Elemente, Tags, Attribute und Hierarchie richtig lesen
XML führt keine Berechnungen aus und enthält von sich aus keine Geschäftslogik. Es ist daher keine Programmiersprache, sondern zunächst eine Syntax zur Beschreibung strukturierter Informationen. Welche Bedeutung Namen wie kunde, adresse oder kundennummer besitzen, legt das jeweilige Datenformat fest.
Ein Kunden-Datensatz zeigt den Elementbaum
<kunde status="aktiv">
<name>Mira Roth</name>
<adresse>
<ort>Frankfurt am Main</ort>
<plz>60311</plz>
</adresse>
<kundennummer>4711</kundennummer>
</kunde>
kundeist das übergeordnete Element und in diesem Beispiel zugleich das Wurzelelement.name,adresseundkundennummersind untergeordnete Kindelemente.ortundplzliegen eine weitere Ebene tiefer innerhalb vonadresse.Mira Roth,Frankfurt am Main,60311und4711sind Textinhalte.status="aktiv"ist ein Attribut des Elementskunde.
Die Verschachtelung bildet eine Eltern-Kind-Hierarchie. Eine Anwendung kann dadurch beispielsweise alle Daten des Kunden lesen oder gezielt zum Ort innerhalb der Adresse navigieren. Ein XML-Dokument ist somit nicht nur eine Folge beschrifteter Zeilen, sondern ein geordneter Baum.
Element und Tag bezeichnen nicht dasselbe
Ein Tag ist die syntaktische Markierung in spitzen Klammern. <name> ist der Start-Tag, </name> der passende End-Tag. Das Element umfasst dagegen die gesamte Einheit aus Start-Tag, Inhalt und End-Tag. Beim Beispiel <name>Mira Roth</name> ist daher nicht nur name, sondern die vollständige Struktur das Element.
Attribute ergänzen Eigenschaften direkt im Start-Tag oder in einem Selbstschluss-Tag. Sie bestehen aus einem Namen und einem in Anführungszeichen gesetzten Wert. Im Kundenbeispiel kennzeichnet status="aktiv" den Zustand des Datensatzes, ohne ein zusätzliches Kindelement anzulegen.
Als praktische Modellierungsregel eignen sich Elemente besonders für umfangreiche, wiederholbare oder weiter unterteilte Inhalte. Kurze Kennzeichnungen und Metadaten werden häufig als Attribute abgelegt. Eine universelle Vorschrift ist das nicht: Der Formatvertrag kann sowohl <status>aktiv</status> als auch status="aktiv" vorsehen. Entscheidend ist, was die empfangende Software erwartet.
Die Reihenfolge von Attributen besitzt in XML keine fachliche Bedeutung. <kunde status="aktiv" id="4711"> bezeichnet insoweit dieselben Eigenschaften wie die umgekehrte Attributreihenfolge. Bei Kindelementen bleibt die Dokumentreihenfolge dagegen erhalten. Ob sie zusätzlich vorgeschrieben ist, entscheidet das konkrete Format, ein Schema oder die Anwendung.
Wurzelelement, Verschachtelung und leere Elemente
Ein vollständiges wohlgeformtes XML-Dokument besitzt genau ein Dokument- oder Wurzelelement. Alle weiteren Elemente müssen darin liegen. Zwei gleichrangige Blöcke wie <kunde>...</kunde> und <rechnung>...</rechnung> ohne gemeinsame äußere Klammerung bilden deshalb kein vollständiges wohlgeformtes Dokument.
Elemente müssen sauber ineinander verschachtelt sein. Nach <kunde><name> muss zunächst </name> und anschließend </kunde> folgen. Eine überkreuzte Folge wie <kunde><name>Mira</kunde></name> verletzt die XML-Grundregeln.
Ein Element ohne Inhalt kann als <notiz></notiz> oder verkürzt als <notiz/> geschrieben werden. Die zweite Form heißt Empty-Element-Tag oder Selbstschluss-Tag. Sie bedeutet nicht zwingend, dass ein Wert unbekannt, null oder fachlich bedeutungslos ist. Diese Interpretation muss das jeweilige Format festlegen.
XML unterscheidet Groß- und Kleinschreibung. <Name> und <name> sind verschiedene Namen; ein Start-Tag <name> darf nicht mit </Name> geschlossen werden. Bereits diese Abweichung kann verhindern, dass ein Parser die Datei einliest.
Wohlgeformt, gültig und namenssicher: XML-Dateien systematisch prüfen
Eine Datei kann korrekt verschachtelt und damit wohlgeformt sein, aber dennoch von einer Schnittstelle abgelehnt werden. Dann liegt der Fehler häufig auf einer zweiten Ebene: Die Datei entspricht nicht dem vereinbarten Schema, verwendet den falschen Namespace, enthält einen unzulässigen Datentyp oder ordnet Elemente anders an als erwartet.
Ein Auftragsbeispiel verbindet Encoding, Namespace und Reihenfolge
<?xml version="1.0" encoding="UTF-8"?>
<auftrag xmlns="urn:beispiel:auftrag:1"
xmlns:adr="urn:beispiel:adresse:1"
version="1.2">
<kunde>
<name>Roth & Partner</name>
<adr:adresse>
<adr:ort>Frankfurt am Main</adr:ort>
</adr:adresse>
</kunde>
<notiz/>
</auftrag>
Die XML-Deklaration steht vor dem Wurzelelement und nennt hier XML 1.0 sowie UTF-8. Encoding beschreibt die Zuordnung zwischen gespeicherten Bytes und Zeichen. Stimmen die tatsächliche Kodierung und die Deklaration nicht überein, erscheinen nicht nur Umlaute möglicherweise falsch: Ein XML-Prozessor kann die Verarbeitung vollständig abbrechen.
Der Standard-Namespace urn:beispiel:auftrag:1 gilt für die unpräfixierten Elemente auftrag, kunde, name und notiz. Das Präfix adr bindet die Adresse an einen anderen Namespace. Ein Präfix ist nur ein lokal gewählter Platzhalter; für die fachliche Identität zählen Namespace-URI und lokaler Elementname. Die URI muss weder eine Webseite öffnen noch direkt auf eine Schemadatei verweisen.
Der Standard-Namespace erfasst unpräfixierte Attribute nicht automatisch. Das Attribut version liegt daher nicht allein aufgrund seiner Position im Auftrags-Namespace. Diese Unterscheidung verursacht in Schnittstellen regelmäßig Fehler, wenn eine Anwendung für ein Attribut einen qualifizierten Namen erwartet.
Im Firmennamen muss das kaufmännische Und als & maskiert werden. Auch ein kleiner-als-Zeichen in gewöhnlichem Text wird als < geschrieben. Solche Escape-Zeichen schützen die Trennung zwischen Nutzdaten und XML-Syntax; sie sind nicht mit URL-Encoding gleichzusetzen.
Prüfworkflow für abgelehnte oder auffällige XML-Dateien
Prüfen Sie XML in einer festen Reihenfolge. Beginnen Sie bei Kodierung und Syntax, bevor Sie fachliche Pflichtfelder untersuchen. Andernfalls suchen Sie möglicherweise nach einem Schemafehler, obwohl der Parser die Datei noch gar nicht zuverlässig lesen kann.
| Prüfschritt | Woran Sie die Regel erkennen | Typisches Fehlerbild | Praktische Folge |
|---|---|---|---|
| 1. Kodierung abgleichen | XML-Deklaration, tatsächliche Dateikodierung und gegebenenfalls Transportangabe müssen zusammenpassen. | Umlaute sind beschädigt oder der Parser meldet ein ungültiges Zeichen. | Speichern oder übertragen Sie die Datei in der vereinbarten Kodierung; eine geänderte Deklaration allein konvertiert keine Bytes. |
| 2. Wurzelelement prüfen | Nach der optionalen XML-Deklaration muss genau ein äußeres Dokumentelement alle übrigen Elemente umfassen. | Mehrere Aufträge stehen ohne gemeinsamen Container nebeneinander. | Die Datei ist nicht wohlgeformt und kann nicht als vollständiges XML-Dokument verarbeitet werden. |
| 3. Tags kontrollieren | Jeder Start-Tag benötigt einen exakt passenden End-Tag; leere Elemente dürfen die Form <notiz/> verwenden. | Ein Tag fehlt, unterscheidet sich in der Großschreibung oder wird zu früh geschlossen. | Der Parser bricht bereits bei der Syntaxanalyse ab. |
| 4. Verschachtelung und Escape-Zeichen prüfen | Elemente dürfen sich nicht überkreuzen; & und < müssen in gewöhnlichen Datenwerten maskiert sein. | Roth & Partner steht unmaskiert im Text oder ein Kindelement endet außerhalb seines Elternelements. | Die Datei ist trotz plausibel wirkender Inhalte nicht wohlgeformt. |
| 5. Namespaces auflösen | Jedes verwendete Präfix benötigt eine Bindung; Namespace-URI und lokaler Name müssen dem Formatvertrag entsprechen. | Das Präfix adr ist nicht deklariert oder verweist auf den falschen Namespace. | Die Anwendung erkennt das Element nicht oder ordnet es dem falschen Vokabular zu. |
| 6. Regelwerk bestimmen | Schnittstellendokumentation, DTD oder XSD legen fest, welche Struktur erwartet wird. | Eine Datei wird nur auf Syntax geprüft, obwohl der Empfänger eine bestimmte XSD-Fassung verlangt. | Wohlgeformtheit ist nachgewiesen, die fachliche Verwendbarkeit jedoch noch nicht. |
| 7. Inhalt validieren | Das Regelwerk kann Pflichtfelder, Datentypen, Wertebereiche, Häufigkeiten und Elementreihenfolgen vorgeben. | kunde fehlt, eine Nummer enthält unzulässigen Text oder notiz steht vor kunde. | Die Datei ist lesbar, scheitert aber an der Schema-Validierung oder späteren Fachverarbeitung. |
| 8. Anzeige und Verarbeitung trennen | Ein Browser zeigt XML häufig als eingerückte Baum- oder Textstruktur, sofern keine eigene Darstellung vorgesehen ist. | Die sichtbaren Tags werden irrtümlich als Fehlermeldung oder unfertige Webseite bewertet. | Testen Sie die Datei mit dem vorgesehenen Empfänger oder Prüfsystem; die Browseransicht beweist weder Gültigkeit noch einen Defekt. |
Ein Parser oder XML-Prozessor liest die Zeichen, erkennt Elemente, Attribute und Textknoten und meldet grundlegende Syntaxfehler. Dadurch versteht er noch nicht, dass 4711 eine Kundennummer oder 1.2 eine Schnittstellenversion sein soll. Diese Bedeutung stammt aus dem Formatvertrag und der verarbeitenden Anwendung.
Die Reihenfolge der Kindelemente bleibt in XML erhalten, ist aber nicht in jedem XML-Format zwingend vorgeschrieben. Ein XSD-Inhaltsmodell mit xs:sequence kann beispielsweise verlangen, dass zuerst kunde und danach notiz erscheint. Ein anderes Schema könnte mehrere Reihenfolgen zulassen. Prüfen Sie deshalb nicht nach einer pauschalen XML-Regel, sondern nach der Spezifikation der Schnittstelle.
Die Dateiendung .xml beantwortet keine dieser Prüffragen. Sie garantiert weder Wohlgeformtheit noch ein bekanntes Schema oder fachlich korrekte Inhalte. Ohne vereinbartes Regelwerk kann ein Werkzeug die Syntax untersuchen, aber nicht automatisch feststellen, ob alle geschäftlich benötigten Angaben vorhanden sind.
Wie Wohlgeformtheit, Gültigkeit und Schema zusammenhängen
Wohlgeformt bedeutet, dass die grundlegenden XML-Regeln eingehalten werden: genau ein Wurzelelement, passende Tags, korrekte Verschachtelung, zulässige Namen und korrekt behandelte Sonderzeichen. Diese Prüfung ist unabhängig davon möglich, ob ein fachliches Schema existiert.
Gültig bedeutet zusätzlich, dass die Struktur einem vereinbarten Regelwerk entspricht. Im klassischen Gültigkeitsbegriff von XML 1.0 ist dieses Regelwerk eine DTD. Im heutigen Schnittstellenalltag wird „gültig“ häufig weiter gefasst und auf eine erfolgreiche Validierung gegen ein Schema, insbesondere XSD, bezogen. Klären Sie deshalb, welches Prüfverfahren der Empfänger tatsächlich verlangt.
Eine DTD beschreibt eine Grammatik für eine Dokumentklasse, etwa erlaubte Elemente, Attribute und Inhaltsmodelle. XSD ist eine eigene XML-Schemasprache und kann zusätzlich detaillierte Datentypen, Wertebereiche, Häufigkeiten und komplexe Strukturregeln ausdrücken. DTDs sind damit nicht automatisch bedeutungslos; ältere oder standardisierte Formate können sie weiterhin verbindlich verwenden.
Ein Schema funktioniert wie ein Strukturvertrag. Es kann festlegen, dass kundennummer verpflichtend ist, höchstens einmal vorkommt und nur einen bestimmten Datentyp akzeptiert. Die XML-Datei <kundennummer>ABC</kundennummer> kann syntaktisch wohlgeformt sein und trotzdem gegen eine geforderte Zahlenregel verstoßen.
Bei konkreten Schnittstellen sollten Sie außerdem die verlangte Schemafassung prüfen. Nicht jedes Werkzeug unterstützt sämtliche Funktionen jeder XSD-Version. Die Aussage „XSD-Datei vorhanden“ reicht daher nicht aus, wenn Sender, Validator und Empfänger unterschiedliche Schema- oder Funktionsstände voraussetzen.
Warum der Browser oft nur die XML-Struktur zeigt
Öffnen Sie eine XML-Datei im Browser, erscheinen häufig eingerückte Elemente oder eine schlichte Textansicht. Das ist zunächst nur eine generische Darstellung der Datenstruktur. XML definiert nicht automatisch, wie ein Auftrag, Feed oder Kundendatensatz grafisch aussehen soll.
Ob der Browser einen Baum, formatierten Inhalt oder eine Fehlermeldung zeigt, kann von Browser, Inhalt, Medientyp und einer gegebenenfalls verknüpften Darstellungsvorgabe abhängen. Für die Diagnose zählt die konkrete Meldung eines Parsers oder der vorgesehenen Fachanwendung, nicht allein die optische Wirkung im Browserfenster.
XML, HTML und JSON: Unterschiede, Einsatzgrenzen und bleibende Praxisfälle
XML, HTML und JSON sind textbasierte Formate, verfolgen aber unterschiedliche Ziele. Spitze Klammern machen XML und HTML optisch ähnlich; sie schaffen jedoch weder dasselbe Vokabular noch dieselben Verarbeitungsregeln. JSON verzichtet auf Tags und bildet Daten mit Objekten, Arrays und primitiven Werten ab.
XML und HTML unterscheiden sich bei Vokabular und Verarbeitung
HTML beschreibt Webdokumente mit standardisierten Elementen wie Überschriften, Absätzen, Links, Formularen und Bildern. Browser kennen die Bedeutung dieser Elemente und besitzen eigene Parsing- und Darstellungsregeln. HTML erlaubt unter bestimmten Bedingungen ausgelassene End-Tags oder unquotierte Attributwerte und verarbeitet fehlerhaften Quelltext häufig tolerant.
XML stellt dagegen kein allgemeines Vokabular für Webseiten bereit. Ein Formatentwickler kann Elemente wie auftrag, kunde oder messwert definieren und über Namespaces bestimmten Vokabularen zuordnen. Dafür sind die XML-Syntaxregeln strikt: Tags müssen korrekt geschlossen und verschachtelt werden.
HTML ist deshalb nicht einfach „XML für Webseiten“. Es ist eine eigene Sprache mit festgelegten Elementen, einem eigenen Datenmodell und besonderen Fehlerbehandlungsregeln. XML dient als erweiterbare Grundlage für anwendungsspezifische Daten- und Dokumentformate.
XML und JSON bilden Daten unterschiedlich ab
JSON ist bei modernen Web-APIs weit verbreitet und bei vergleichbaren Daten häufig kompakter. Es kennt Objekte, Arrays, Strings, Zahlen, boolesche Werte und null. Arrayelemente sind geordnet; die Mitglieder eines JSON-Objekts gelten semantisch nicht als geordnete Folge.
XML organisiert Informationen als Elementbaum mit Text, Attributen und Namespaces. Ohne Schema ist gewöhnlicher Elementtext zunächst Text; XSD kann ihm Datentypen und zusätzliche Regeln zuweisen. XML eignet sich außerdem für dokumentorientierte Inhalte, in denen Text und untergeordnete Elemente gemischt auftreten können.
Schema-Validierung ist kein ausschließliches XML-Merkmal. Auch JSON kann mit JSON Schema beschrieben und validiert werden. XML verfügt jedoch über langjährig etablierte DTD- und XSD-Werkzeuge, Namespaces und Formatkonventionen, die in bestehenden Standards und Schnittstellen fest verankert sein können.
Die Auswahl richtet sich daher nicht nach einer pauschalen Rangfolge. Erwartet eine Schnittstelle XML mit einem bestimmten Namespace und Schema, ist eine inhaltlich ähnliche JSON-Datei kein austauschbarer Ersatz. Bei einer neu entwickelten, reinen Daten-API kann JSON dagegen weniger Markup benötigen und sich unmittelbar in viele Programmiersprachen übertragen lassen.
Warum XML weiterhin in Dateien und Schnittstellen vorkommt
XML ist nicht lediglich ein Vorläufer von JSON. Eine XML-Sitemap nutzt ein festgelegtes Wurzelelement, einen Namespace, UTF-8 und maskierte Datenwerte. Atom definiert ein XML-basiertes Feedformat. Solche Standards lassen sich nicht ohne Weiteres durch eine anders strukturierte JSON-Datei ersetzen.
Auch Office-Open-XML-Dateien wie .docx, .xlsx und .pptx verwenden XML-Teile innerhalb eines Paketformats, das technisch als ZIP-Archiv organisiert ist. Das bedeutet nicht, dass jeder Paketbestandteil reines XML ist. Ältere Formate wie .doc, .xls und .ppt dürfen ebenfalls nicht mit diesen Open-XML-Paketformaten gleichgesetzt werden.
Langfristig gepflegte Schnittstellen behalten XML häufig bei, weil Schemas, Validierungsprozesse, Signaturen, Werkzeuge und angeschlossene Systeme darauf abgestimmt sind. Eine Umstellung erzeugt nicht automatisch einen fachlichen Vorteil. Sie kann neue Konverter, Tests und Versionsregeln erfordern und dabei bestehende Kompatibilität gefährden.
Häufige Fragen zu XML
Was bedeutet XML?
XML bedeutet Extensible Markup Language. Die erweiterbare Auszeichnungssprache beschreibt strukturierte Daten mit frei definierbaren Elementnamen, Attributen, Text und hierarchischer Verschachtelung.
Ist XML eine Programmiersprache?
Nein. XML beschreibt und strukturiert Informationen, führt aber keine Anweisungen oder Berechnungen aus. Programme lesen XML und wenden anschließend ihre eigene Logik auf die enthaltenen Daten an.
Was ist ein XML-Tag?
Ein Tag ist eine syntaktische Markierung wie <name> oder </name>. Start- und End-Tag begrenzen ein Element. Ein leeres Element kann mit einem Selbstschluss-Tag wie <notiz/> dargestellt werden.
Was ist ein Attribut?
Ein Attribut ist eine Name-Wert-Eigenschaft im Start- oder Selbstschluss-Tag, etwa status="aktiv". Es ergänzt das Element, ohne ein eigenes Kindelement zu bilden.
Was ist ein XML-Schema?
Ein Schema legt erlaubte Elemente, Attribute, Reihenfolgen, Häufigkeiten und gegebenenfalls Datentypen fest. XSD ist eine verbreitete XML-Schemasprache; eine DTD ist eine weitere, in XML 1.0 verankerte Grammatikform.
Was ist der Unterschied zwischen XML und HTML?
HTML verwendet ein standardisiertes Vokabular zur Strukturierung und Darstellung von Webdokumenten. XML erlaubt anwendungsspezifische Elementnamen und beschreibt eigene Daten- oder Dokumentstrukturen nach strengeren Syntaxregeln.
Was ist der Unterschied zwischen XML und JSON?
JSON bildet Daten mit Objekten, Arrays und primitiven Werten meist kompakt ab. XML nutzt Elemente, Attribute, Text und Namespaces und kann dokumentorientierte Mischinhalte ausdrücken. Beide Formate lassen sich mit passenden Schemas validieren.
Warum nutzen manche Programme noch XML?
Standards und langjährig betriebene Schnittstellen stützen sich häufig auf definierte Namespaces, DTDs oder XSD-Schemas. XML bleibt dort Bestandteil des Formatvertrags; ein Wechsel zu JSON würde alle beteiligten Systeme, Prüfungen und Prozesse betreffen.
XML ist sinnvoll oder zwingend, sobald ein Standard, Dateiformat oder Empfänger es verlangt. Für neu entworfene reine Daten-APIs kann JSON kompakter sein. Prüfen Sie vor jeder Verarbeitung vor allem den Formatvertrag, die Kodierung, den Namespace und das verlangte Schema – nicht nur die Dateiendung.
Werbung
(**) UVP: Unverbindliche Preisempfehlung
Preise inkl. MwSt., zzgl. Versandkosten