Spätestens seit dem Softwareentwicklungspraktikum habe ich eine gefühlte Lücke in meiner gedanklichen Werkzeugkiste: Wie repräsentiere ich einfache Daten mit wenig Aufwand möglichst gut lesbar für Mensch und (verschiedene) Maschinen?
Die heute kanonische Antwort scheint stets XML als standardisiertes Metadatenformat mit vielfältiger Toolunterstützung zu sein. In manchen Fällen mag das gerechtfertigt sein, mir erschien der Overhead insbesondere bei einfachen Datenstrukturen aber unangebracht; insbesondere das Monster DomParser hat uns viele Flüche entlockt. Wir stiegen dann auf JDOM um, was zumindest eine angenehmere Bibliothek ist, aber natürlich am sperrigen Datenformat nichts ändert. Auch sind XML-Sprachen oft kaum bis gar nicht lesbar, weil man sich durch abstrakte Elemente und Namespaces wühlen muss.
Beim Prokrastinieren fand ich heute Hinweise auf JSON. Diese schlanke Sprache füllt meine Lücke insofern, als dass sie für die meisten Daten relativ simpler Struktur ein sehr einfaches Darstellungsformat bietet, das für jeden Programmierer intuitiv verständlich sein sollte. Dabei geht es von Objekten aus, die sich durch Paare aus Schlüsseln und Werten auszeichnen. Andere Objekte sind dabei als Werte natürlich erlaubt. So könnte man zum Beispiel formulieren:
{
"titel" : "Beispielbuch",
"autoren" : ["Max M.", "Jutta J."],
"isbn" : 123456789,
"verlag" : {
"name" : "Beispielverlag",
"ort" : "Musterstadt"
},
"taschenbuch" : false
}
Würde man XML nutzen wollen, sähe das vielleicht so aus:
Beispielbuch Max M. Jutta J. 123456789 Beispielverlag Musterstadt false
Hier missfällt mir spontan, dass nicht klar ist, ob man einen Wert nun als Element oder Attribut modellieren sollte. Auch fällt direkt auf, dass viel Text nur für die Strukturierung der Daten mit Tags aufgebracht werden muss und so die Lesbarkeit verschlechtert.
Die offizielle Homepage liefert umfassende Informationen zu JSON und eine Liste mit vielen Sprachen, für die bereits Bibliotheken für die Arbeit mit JSON existieren. Ganz unten finden sich noch einige Links zu interessanten Beiträgen unter anderem zur Diskussion “XML vs. JSON”.
Ich bin froh, JSON heute entdeckt zu haben, und werde bei nächster sich bietenden Gelegenheit austesten, wie es sich in ein System integrieren lässt. Eine Allzweckwaffe ist JSON sicher nicht: Da es eine reine Syntaxdefinition ist, gibt es keine Semantik hinter der Darstellung. Jegliche Form von Restriktionen an Daten muss daher von jedem verarbeitenden Programm selbst validiert werden; ein universeller Validator, wie es ihn für XML gibt, ist nicht denkbar. In Kontexten, wo man sich auf die Einhaltung von Konventionen verlässt, ist das möglicherweise aber ohnehin nicht nötig.
Was ist eigentlich mit dem guten alten Windows-ini-Format passiert? Mir scheint, dass hier ganz oft Räder neu erfunden werden, die eigentlich schon längst im Schuppen liegen…
Einschränkend ist natürlich, dass Kategorien nicht geschachtelt sein können und die Werte der Schlüssel-Wert-Paare immer atomar sein müssen. Aber ich glaube, es gibt nicht viele Aufgaben, für die ini zu wenig mächtig und XML zu aufwändig ist.
Es kommt von MS!
JSON ist ja anscheinend ursprünglich als Literalschreibweise für Objekte entstanden. Und von “neu erfunden” kann ja keine Rede sein, es ist auch schon 10 Jahre alt.
Insbesondere kann man es zur Serialisierung von Objekten verwendet werden, zumindest solchen von JavaScript; ich wüsste aber nicht, was grundsätzlich gegen seine Verwendung für andere Sprachen spricht.
Eine Tiefenserialisierung kann man ohne nichtatomare Werte möglicherweise über eindeutige Identifier realisieren. Mit Objektliteralen ist das aber schon schöner.
Dann wär’s aber ja nicht mehr einfach lesbar.
Du meinst mit IDs? Stimmt.
Wenn du aber eine “flache” Serialisierung willst bzw. einfach eine sinnvolle Serialisierung eines Geflechts, das kein Baum ist, brauchst du sie ohnehin. Wobei es ja auch Serialisierungsschemata gibt, die definiert aus jedem Geflecht einen Baum machen. Die spiegeln dann nicht die tatsächliche Situation wider, funktionieren aber ohne IDs.