Summary

  • RFC 2376 registrierte text/xml und application/xml, doch ein fehlender charset führte zu gegensätzlichen Regeln: US-ASCII beim ersten Typ trotz BOM oder XML-Deklaration, XML-eigene Erkennung beim zweiten.
  • Registrierung, empfangener Header, Oktette, Prioritätsregel und Anwendungsbedeutung waren getrennte Belege. RFC 7303 glich die Typen später an und beseitigte den alten stillen Standardwert.

Ein selbstbeschreibendes Dokument in einem fremden Rahmen

XML sollte Struktur zwischen unterschiedlichen Rechnern und Programmen transportieren. Eine interne Deklaration konnte die Kodierung benennen; eine Byte-Reihenfolge-Markierung half, wichtige Darstellungen vor dem Lesen des Inhalts zu erkennen.

Über HTTP, E-Mail oder WebDAV kam das Dokument jedoch in einer MIME-artigen Hülle an. Auch Content-Type konnte einen charset tragen. Der Empfänger erhielt somit mehrere mögliche Antworten auf die Frage, welche Zeichen die Oktette darstellten.

RFC 2376 erschien im Juli 1998 als Informational-Dokument. Sie führte text/xml und application/xml ein und lehnte die ungenaue Wiederverwendung von SGML-Typen ab. Gemeinsame Namen waren notwendig; die schwierige Frage betraf die Rangfolge der Angaben.

Eine Darstellungswahl veränderte die Autorität

Jede XML-Entität konnte als application/xml übertragen werden. Ein Agent ohne XML-Unterstützung durfte sie als undurchsichtige Datei behandeln. text/xml signalisierte dagegen, dass eine Klartextanzeige ein angemessenes Standardverhalten sei.

Mit dieser Bequemlichkeit kamen die historischen Regeln des MIME-Obertyps text. War ein charset ausdrücklich vorhanden, erklärte RFC 2376 ihn bei beiden Typen zur maßgeblichen Angabe. Die interne XML-Deklaration gewann nicht automatisch.

Ohne Parameter trennten sich die Wege. Bei application/xml lieferte der Header keine Kodierungsinformation. Ein XML-fähiger Prozessor durfte BOM, Anfangsmuster und interne Deklaration prüfen; ein XML-unwissender MIME-Agent sollte nichts annehmen.

Bei text/xml bedeutete das Fehlen dagegen US-ASCII. Das galt auch über HTTP und selbst dann, wenn der Inhalt UTF-8 oder UTF-16 war und dies erklärte. Ein leeres Feld bewahrte keine Ungewissheit, sondern aktivierte eine geerbte Anweisung.

Das Beispiel machte den Widerspruch zwingend

RFC 2376 zeigte eine Entität mit UTF-16-BOM und encoding="utf-16", aber nur dem Typ text/xml. Das vorgeschriebene Ergebnis blieb US-ASCII. Dem Dokument zu glauben hieß, gegen den Liefervertrag zu handeln.

Unter application/xml erhielten dieselben Hinweise Gewicht. Ohne charset konnte das BOM UTF-16 bestimmen; ohne BOM halfen Anfangsmuster und Deklaration. Ein Wort im äußeren Typ änderte, welcher Beleg galt.

Die Folge reichte in Speicherung und Vermittlung. Ein Gateway konnte den Inhalt transkodieren und nur den externen charset aktualisieren. Ein Archiv konnte den Header entfernen, von dem die Auslegung abhing. Wer Bytes und Kontext trennte, verlor womöglich den Grund ihrer Lesart.

Selbstbeschreibung bestimmt nicht ihren eigenen Rang

XML 1.0 überließ die Priorität bei externer Information dem höherliegenden Übertragungsprotokoll. Das war plausibel, weil Vermittler die Darstellung ändern konnten, ohne dass das Dokument davon wusste.

Damit wurde Kodierung auch zu einer Kontrollfrage: Welche Schicht darf welche andere überstimmen? Bedeutet Abwesenheit Unwissen oder einen Standardwert? RFC 2376 übernahm einen Teil ihrer Antwort aus der MIME-Geschichte.

RFC 3023 ersetzte sie 2001 und behielt den US-ASCII-Standard für text/xml. Sie erklärte ausführlicher, warum ein externer charset bei Transkodierung nützlich war. Implementierungspraxis und Regeln textueller Medientypen entwickelten sich weiter.

Die Reparatur entfernte eine verborgene Entscheidung

RFC 6657 verlangte, dass neue Texttypen ihr charset-Verhalten festlegen. RFC 7303 glich 2014 text/xml an application/xml an. Die Wahl des Obertyps text sollte nicht mehr allein die Dekodierung bestimmen.

Die heutige Reihenfolge betrachtet zuerst ein BOM, ohne BOM einen ausdrücklichen MIME-charset und ohne beides die XML-Regeln. application/xml bleibt empfohlen, um die historische Verwirrung zu meiden.

Die Endung +xml trennt außerdem Syntax und Zweck. Ein spezialisierter Typ kann generische XML-Werkzeuge zulassen und dennoch die Art des Dokuments benennen. Einen Baum zu bauen beweist weder Verständnis des Vokabulars noch sichere Ausführung.

Ein Registereintrag ist kein Ausführungsnachweis

Das aktuelle IANA-Register verweist bei application/xml und verwandten Typen auf RFC 7303. Es belegt Namenskoordination, nicht den tatsächlich empfangenen Header, unveränderte Bytes, die Parserentscheidung oder die Anwendungswirkung.

Lu Hengs Realitätsschichten trennen registrierten Typ, erfassten Header, Oktette, BOM, Deklaration, dekodierte Zeichen, Baum und Handlung. Running-Code Primacy verlangt die Beobachtung von Objekt und Prozessor. Minimum Initial Specification erlaubt zugleich ein faires Urteil: RFC 2376 schuf einen nützlichen gemeinsamen Einstieg; spätere Normen entfernten verborgene Autorität aus einem Standardwert, nicht die Koordination selbst.