Warum JSON oder XML

[Tim Tepaße]

Hallo,

Aber warum mit Haubitzen auf Mücken schießen? In eine responseText kann ich auch komplizierte Datenstrukturen schreiben und mit simplen Methoden wie z.B. split() wieder DOMgefällig machen.
Sagt mal bitte, wann brauche ich XML oder JSON?

Du bastelst ein Textformat für eine Datenstruktur und dazu Code, um Daten in Text zu transformieren und anderen Code, um Text wieder in Daten zu bekommen.
Du bastelst ein weiteres Textformat für eine andere Datenstruktur und dazu weiteren Code, um Daten in Text bekommen und weiteren, anderen Code, um Text wieder in Daten zu bekommen.
Du bastelst noch ein anderes Textformat für wieder eine andere Datenstruktur und dazu wieder weiteren Code, um Daten in Text umzuwandeln und wieder weiteren Code und Text wieder in Daten zu verwandeln.

Irgendwann danach guckst Du Dir die Menge an Quellcode an, die sich mit Text-Umwandlungen beschäftigt und vergleichst diese Menge mit der Menge an Quellcode, in der Du tatsächlich was mit den bekommenen Daten anfängst.

Schlimmer noch, Du hast Muster erkannt, es gibt verschiedene Datentypen in Deinen unterschiedlichen Struktur wie Zahlen, Strings, Wahrheitswerte, Zeitstempel und anderes. Und Du erkennst verschiedene Muster der Sammlungen von einzelnen Datentypen, wie Aufzählungen, Zuordnungen und Mengen von skalaren Werten. Und Du siehst diese Muster immer öfters, wenn Du nur darauf achtest.

Anfangs kann es Spaß machen, solche Probleme für sich selbst von Grund auf zu lösen. Aber wenn man in seinem Projekt eigentlich was anderes machen will und die Textverarbeitung nur Mittel zum Zweck sein soll, dann nervt das irgendwann. Wenn man etwas wieder und wieder in leichter Variantion macht, dann will man das Problem wegabstrahieren und sich nur noch um die leichten Variationen kümmern müssen. Dann kommt man dann vielleicht auf den Gedanken einer Metasyntax, die viele der obigen Muster vereint.

Die Frage, welches Metaformat verwenden soll, hängt von vielem Zeugs ab. Schreibbarkeit, wenn es von Menschen editiert werden soll. Definierte Datentypen, in Abhängigkeit der eigenen Daten. Eine mögliche Verarbeitbarkeit durch eine Toolchain wie Validierung, Minimierung. Die Kapazitäten von Sender und vor allem vom Empfänger. Die Serialisierungsmöglichkeit eigener, selbst definierter Datentypen. Lesbarkeit für das Debuggen. Einfachheit der Implementierung. Die eventuelle Zielgruppe anderer Software-Entwickler, die die eigene Schnittstelle benutzen müssen. Usw. usf.

Im Browser würde ich mich so entscheiden:

• Wenn nur ein skalarer Wert übertragen wird, dann den Wert einfach in den HTTP-Response-Body packen.

• Wenn nur eine flache Liste mehrerer gleicher Werte übertragen werden soll, auch in den Response-Body, zeilenbasiert, split(). Bei einer Zuordnung könnte man sich auch überlegen, das RFC-822-X-Header-System von HTTP-Messages zu überladen.

• Wenn eine verschachtelte, Baum-artige Datenstruktur übertragen werden sollen ...
• Wenn mehrere unterschiedliche in JS-abbildbare Datentypen übertragen werden sollen ...
• Wenn eine Mischung aus Zuordnungen und Listen von Werten übertragen werden sollen ...
• Wenn ich genau die serverseitige Datenstruktur auch in Javascript nutzen will ...
• Wenn ich vorher nur einen groben Überblick über die zu erwartenden Daten habe ...
... dann jeweils in JSON. Das definiert zwar nur eine Untermenge von Daten und deren Strukturen, aber eine sehr sinnvolle, weil diese sich genau in Javascript und vielen serverseitigen Sprachen ohne der Definition eigener Objekttypen abbilden lässt. Die Lesbarkeit beim Debuggen ist nahe an der Vorstellung dessen, was man im Browser verarbeitet. Und eine sichere, eval-lose Verarbeitung ist immer noch sehr klein in der Codemenge. JSON hat da einfach einen sehr intelligenten Platz gefunden.

• Wenn ein strukturiertes Dokument mit viel (Text)-Inhalt übertragen und direkt ins Browser-Dokument eingefügt werden soll, dann mit XML (Oder HTML im Response-Body und dann innerHTML).

Außerhalb des Browsers gibt es ja auch einen Haufen von Metasyntaxen; dort entscheide ich mich ungefähr wie folgt, wenn ich die Wahl habe:

• Für eine Liste von einzelnen Werten eine Textdatei mit einer Zeile pro Wert. Wunderbar zu verarbeiten mit UNIX-Tools.

• Für eine Liste von Records: charakter separated values (CSV). Auch nett zu verarbeiten mit UNIX-Tools.

• Für Daten, auf die ähnliches zutrifft wie die obigen JSON-Problemfälle: YAML. Es kann diverses mehr als JSON oder Nextstep ASCII Property Lists, deswegen nutze ich es aber nicht. Stattdessen finde ich es allein wegen der arg reduzierten Schreibweise toll. Künstliche Delimiter wie eckige oder geschweifte Klammern sind optionale Schreibweisen, es gibt auch eine durch natürliche Notation inspirierte Schreibweise, die mir sehr, sehr, sehr zusagt. YAML ist meiner Meinung nach dafür gedacht, editiert zu werden, JSON oder PLists, die gleiches leisten, sind eher dafür gedacht, leichter von Parsern verarbeitet zu werden.

• Markdown für leicht strukturierte Texte, die dennoch maschinell verarbeitet (= zu HTML umgewandelt) werden sollen. Wie bei YAML finde ich die Syntax hier sehr an meinen normalen Gewohnheiten beim Schreiben reines Textes orientiert.

• XML würde ich nicht für Konfigurationen oder reine Datenstrukturen nehmen, sondern für stark strukturierte Texte, mit einem definierten Vokabular von Strukturen, Texte die mit anderen zusammen erarbeitet werden und die von einer Standard-Toolchain verarbeitet werden sollen. SDML ist ein gutes Bespiel einer XML-Anwendung, finde ich. Ein schlechtes Beispiel für XML-Anwendung sind Konfigurationssyntaxen. Dort sind die Zuordnungen meist nur kleinere Werte, durch die XML-Syntax hat man dann mehr XML-Metasyntax auf dem Bildschirm denn tatsächliche Werte.

Andere Metasyntaxen:

Das Datenmodell von RDF ist genial für die Abbildung von (zyklischen) Graphen, bei denen Ecken und Kanten alle möglichen selbst definierten Typen von Ecken und Kanten sein. Das Textformat RDF/XML ist gräußlich, mit Notation3 oder Turtle gibt es aber sehr nette andere Syntaxen.

Lisper rufen natürlich nach der Meta-Syntax schlechthin, nach S-Expressions, die wiederum alles bedeuten können. Auch ein nettes Konzept, aber wohl eher mächtiger, wenn man es mit einem S-Expressions-verarbeitendem Prozessor verarbeitet.

Bin ich ins Abschweifen gekommen? Tschuldigung.

Tim