Die Kernaussage lautet: 44% einer Stichprobe von n=5096 Feeds von Syndic8 sind nicht wohlgeformt, also ist XML am Ende.
Das zugrundeliegende Problem hat allerdings strenggenommen nichts mit XML zu tun, sondern mit Zeichensätzen und der Art und Weise, wie Daten per HTTP übertragen werden.
XML.com: XML on the Web Has Failed [via cyDome - Fast die Hälfte der RSS-Feeds ist ungültig]
Zeichensätze gibts wie Sand am Meer. Da wären zunächst mal die alten Bekannten ASCII und ANSI, die Veteranen unter den Zeichensätzen. ASCII, aus dem Jahre des Herren 1968, umfasst einen Zeichensatz von 2^7, also 128 Zeichen, kodiert in einem Byte pro Zeichen. Darin enthalten sind 32 nicht sichtbare Steuerzeichen, das lateinische Alphabet in Groß- und Kleinschreibung, die Ziffern von 0-9, nordamerikanische Satzzeichen und ein paar Sonderzeichen, die man zum Programmieren braucht. Keine Äs und ßs, keine spanischen Satzzeichen, keine französischen Anführungsstriche.
Danach kam ANSI, bzw. ISO 8859. Immerhin 256 Zeichen, und damit auch die wichtigsten Sonderzeichen. Allerdings immer noch nur für Sprachen mit lateinischem Alphabet. Hier leistete sich Microsoft eine Extrawurst. Man baute den auch Latin-1 genannten ISO 8859-1 um nannte ihn Windows-ANSI.
Die ISO 8859-Familie besteht aus ca. 16 Zeichensätzen. Wieso ca.? Weil der keltische Zeichensatz zwar geplant (die Nummer wurde sozusagen reserviert) aber nie verabschiedet wurde. Die ISO 8859-Zeichensätze für arabisch, kyrillisch und andere nicht-lateinische Alphabete sind teilweise unzureichend umgesetzt. Zum einen Aufgrund der Beschränkung auf 256 bzw. 224 (32 Steuerzeichen) Zeichen, zum anderen weil es bessere Alternativen gibt.
Auftritt Unicode. Unicode stellt einen Versuch dar, alle Zeichen aller lebenden Sprachen abzubilden. Dazu sieht der Standard pro Alphabet eine Zeichentabelle vor. Die Zeichen selbst sind durchnummeriert von 0 bis 65535. Unicode kennt also 65536 verschiedene Zeichen für eine ganze Reihe von Schriftsätzen, darunter das Runenalphabet, Braille oder graphische Elemente.
Unicode bläht (vier Bytes pro Zeichen, 2^16 = 65536) jeden ASCII-Text um das Vierfache auf. Heutzutage kein so großes Problem mehr, das durch relativ billige Massenspeicher gelöst werden kann.
Nein, Unicode bläht nicht jeden ASCII-Text um das Vierfache auf. Es gibt Varianten, die jedes Zeichen mit nur zwei Byte darstellen, die Textgröße also nur verdoppeln. Und es gibt eine 1-Byte-Variante, da ändert sich nichts an der Größe und sogar eine 7-bitige Variante, die nur die 2^7 ASCII-Zeichen enthält.
Daneben gibt es noch Windows-1252 , MacRoman und bestimmt noch ein paar andere, die ich nicht kenne.
Zurück zur Aussage, XML hätte im Web versagt. XML sieht vor, das für jedes Dokument explizit der Zeichensatz angegeben wird, mit dem es erstellt wurde und zu Lesen ist. Soweit kein Problem, als XML-Entwickler weiß man dies und implementiert es entsprechend.
Wird eine XML-Datei (das könnte im Sinne dieses Textes ein HTML-, ein XHTML- oder ein Feed-Dokument in RSS, RDF oder Atom sein), markiert als mit ISO 8859-1 erstellt, nun über das Web-Protokoll HTTP an einen Browser geschickt, so gibt HTTP der Datei einen HTTP-Header mit. Und in diesem findet man neben neben allen möglichen technischen Daten auch eine Angabe für den verwendeten Zeichensatz. Das Problem dabei: woher weiß HTTP, welche Zeichensatzangabe es in den Header packen soll?
In der Regel geschieht dies durch Konfiguration des Webservers, der die Datei verschickt und dafür sorgt, einen ordnungsgemäßen Header mitzuliefern. Der Server steht in den USA und sendet alle Dokumente mit der Zeichensatzangabe us-ascii aus. Dumm nur, wenn im XML-Dokument aber iso-8859-15 steht, weil zum Beispiel das EURO-Zeichen vorkommt, das der Zeichensatz US-ASCII nicht kennt.
Welche Angabe also sollte das verarbeitende Programm, hier der Browser, benutzen? Der XML-Standard sagt hierzu deutlich, das die Angabe des übergeordneten Systems zu verwenden ist. XML wird über HTTP übertragen, also wird die Angabe im Dokument ignoriert und der HTTP-Header zur Entscheidung der Zeichensatzfrage herangezogen.
Der sagt us-ascii, dieser Zeichensatz kennt kein EURO-Symbol, das Dokument ist nicht wohlgeformt, peng.
Der Autor geht an dieser Stelle erstmal frühstücken. Bis später.
Wobei die Anwendung des HTTP Headers hier der Fehler im Standard ist. Denn die Idee ist selten blöd: der HTTP Server kann nur Aussagen über Gruppen von Files machen - er hat keine Sicht in die einzelne Datei hinein. Daher ist seine Angabe immer eine “gröbere” als die explizite in der Datei. An vielen anderen Stellen wird deshalb nicht von ungefähr darauf hingewiesen das Inhalte der Datei über dem Serverheader vorrang haben sollten. Bestes Beispiel ist HTML, wo diverse Angaben aus der Datei selber genommen werden (über den Doctype) und nicht über das sehr magere text/html vom Server.
Übrigens sagt das zitierte Stück aus der XML Spec nicht, das das übergeordnete Protokoll den Zeichensatz bestimmt, sondern nur, das die Prioritäten im übergeordneten Protokoll definiert werden - es sagt also nur, das man bei Fragen der Inkonsistenz zwischen HTTP und XML Zeichensatz die HTTP Protokoll Spec lesen muss um zu wissen welcher Zeichensatz gilt. Und blöderweise haben die HTTP Spec Schreiber den Fakt das XML auch eigene Zeichensatzangaben enthalten kann ignoriert.
Klar, mit Regelhuberei kann man den Untergang von XML ausrufen, aber mit etwas Nachdenken und pragmatischer Vorgehensweise kommt man trotzdem zum Ziel. Selbstverständlich stören falsche Implementierungen von Standards, aber bei Mark Pilgrim ist das eher Teil seiner Selbstdarstellung.
Die Aussage “XML on the Web has failed” an RSS festzumachen ist … sagen wir töricht. In der Rangliste der mangelhaft ausgereiften, schlecht dokumentierten an XML angelehnten (anders kann man das nicht nennen) Formate belegt RSS den 2. Platz. (Platz 1. geht an OPML.) Mit XML an sich hat das im Grunde nichts zu tun.
Xml sieht ab der Version 1.1 ohnehin vor, daß in der ersten Zeile die Xml-Declaration mit version=’1.1’ und encoding notiert ist und als Zeilenumbruch #85 (NEL) oder #2028 (Unicode-Zeilentrenner) verwendet wird. Dies kann nur funktionieren, falls die speziellere Anweisung im Xml-Dokument die http-Information bricht.
Dasselbe funktioniert bei Mails ja schon längst: Der Body ist in us-ascii codiert und teilt bsp. mit, daß es sich um ein multipart/alternative - Dokument handelt, jeder Part informiert selbst über seine Codierung.
Schließlich verschwindet das Problem inzwischen, falls sowohl im http-Header als auch in der Xml-Declaration utf-8 genutzt wird.
Xml sieht ab der Version 1.1 ohnehin vor, daß in der ersten Zeile die Xml-Declaration mit version='1.1' und encoding notiert ist und als Zeilenumbruch #85 (NEL) oder #2028 (Unicode-Zeilentrenner) verwendet wird. Dies kann nur funktionieren, falls die speziellere Anweisung im Xml-Dokument die http-Information bricht.
Dasselbe funktioniert bei Mails ja schon längst: Der Body ist in us-ascii codiert und teilt bsp. mit, daß es sich um ein multipart/alternative - Dokument handelt, jeder Part informiert selbst über seine Codierung.
Schließlich verschwindet das Problem inzwischen, falls sowohl im http-Header als auch in der Xml-Declaration utf-8 genutzt wird.