Nachteile von JSON?

[spobat]

Ich habe mir gerade diesen Artikel durchgelesen, in dem der Autor die Frage aufwirft, was wohl nach XML und JSON kommen mag.

it [JSON] lacks some desirable traits. Two of them are that it has no support for a date data type and it doesn't support comments.

Was mir nicht ganz klar ist, ist wofür man einen eigenen Datentyp für Date einführen/brauchen sollte. Ein long-timestamp sagt etwas über die genaue Zeit aus, ist effizient und belegt (idr.) nur 8 Byte.
Warum man beim Austausch von Daten (client-server, z.B. node.js) Kommentare haben wollen würde, ist mir auch nicht ganz klar.

Wenn man den Halbsatz vor dem obigen Zitat mit einbezieht, dann ergibt das vielleicht mehr Sinn:

However, as its use has been extended to new areas, such as databases,

Bleibt nur noch die Frage: Wieso sollte man innerhalb einer Datenbank Informationen als JSON abspeichern? Ist "binär" da nicht mit großen Vorzügen die ungeschlagene #1?
JSON für Datenbanken zu benutzen, hört sich für mich ein wenig wie "Missbrauch" an.
PS: In "Date" sehe ich nach wie vor kein Problem (Zeitzone könnte ein 2. int sein).

[Niki]

Beim Datum rate ich mal ins Blaue. Wenn du einen UTC+0 Timestamp hast, dann kannst du den direkt als Zahl im JSON ablegen (also nicht als String), weil du einfach 1234567890 nutzen kannst. Willst du nun aber eine Zeitzone einbeziehen, z.B. UTC+1, dann hast du plötzlich 1234567890+0001. Letzteres ist keine einfache Zahl mehr, sondern benötigt im JSON eine Darstellung als String. Und das bedeutet Parsen um das Datum zu berechnen.

EDIT: Ein weitere Grund warum ein Datum fehlt ist das jeder seinen eigenen Kram macht und es keinen Standard für Daten gibt. Viele Server-APIs nutzen für Daten, die nicht UTC+0 sind, so was wie... "YYYY/MM/DD hh:mm:ss". Andere benutzen vielleicht "DD/MM/YYYY hh:mm". Und wieder andere mögen's noch anders. Ich kenne sogar Fälle wo derselbe Server in unterschiedlichen Requests verschiedene Datumsformate benutzt. Da kriege ich jedes mal einen kleinen Hassanfall :)

EDIT 2: Noch ein Grund wäre wenn du JSON tatsächlich als Datenbank benutzt. Wenn du dann ein Programm hast das einfach nur die Datensätze einer x-beliebigen JSON Datenbank anzeigen soll, dann kann das Programm ohne weitere Informationen nicht wissen ob es sich bei einem Element um ein Datum handelt oder nicht.

[Artificial Mind]

Wir nutzen bei uns in Upvoid auch sehr viel JSON. Das mit den Kommentaren ist uns auch bereits aufgefallen und wir werden wahrscheinlich einfach unseren Parser dementsprechend erweitern.

Das mit Datum finde ich allerdings keinen schwerwiegenden Nachteil. Man kann es auf verschiedenste Art und Weise definieren.

[Niki]

Das mit den Kommentaren ist uns auch bereits aufgefallen...

Ich nehme an es handelt sich bei euch um JSON Daten die nicht das Resultat einer Server-Kommunikation sind? In so was wie JSON Konfigurationsdateien wären Kommentare schon nett.

[spobat]

Einen Parser, der die gängigen Javascript-Kommentare kennt (/* */, //, wie bei c++), um diese funktionalität zu erweitern sollte nicht so schwierig sein. 2 RegExen und die beiden Kommentartypen sind "weggestrippt." Deshalb sehe ich in der ""fehlenden"" Kommentarfunktion wenig Nachteil.

[Artificial Mind]

Ich würde das nicht über Regexe machen. Es können sich ja sehr gut Kommentare in Strings "verstecken" und den Regex Strings + Escape Sequences in Strings unterstützen zu lassen halte ich für sehr fehleranfällig. Lieber den Parser erweitern.

[spobat]

Das ist bestimmt die sicherere Variante, yep.

[Artificial Mind]

Mal als Referenz: Wir nutzen Picojson ( https://github.com/kazuho/picojson ), das ist BSD Lizenz, nur eine Header-Datei und einigermaßen lesbar. mMn schön und minimalinvasiv ;)

[waigie]

Auch wenn es ein leichtes ist einen JSON Parser um die Möglichkeit von Kommentaren zu erweitern, ist es trotzdem schade, dass JSON Kommentare nicht standardmäßig unterstützt.
Wenn JSON Konfigurationen zwischen Projekten kompatibel sein sollen, ist eine nicht standardkonforme Implementierung immer schwierig, da die Implementierungen in den Projekten nicht zwangsläufig identische Möglichkeiten bieten.

[Jeason]

Ein Nachteil ist man keine Multiline Strings haben kann. Natürlich könnte man aber auch den Parser in dem Fall einfach erweitern ;-)

[Jonathan]

Naja, Parser erweitern kann man natürlich machen. Aber darum geht es im Grunde genommen gar nicht.
Ich meine, sowohl XML als auch JSON sind jetzt keine schwarze Magie, da kann man auch an nem Wochenende seinen eigenen Parser schreiben. Oder sich eine ganz eigene Syntax überlegen. Beides sind ja im Grunde keine Dateiformate sondern nur Darstellungsarten von beliebigen Daten.
Meiner Meinung nach liegt der Vorteil von solchen Text-Dateien vor allen Dingen darin, dass sie sich selber beschreiben. Man muss also nicht unbedingt einen eigenen Editor schreiben, sondern kann die Dateien auch im Texteditor verändern. Und wenn man sie einlesen will, braucht man im Zweifelsfalle keine Spezifikation, sondern schaut sich die Datei einfach an und liest die entsprechenden Werte aus. Von daher sind Kommentare gerade in solchen Dateien total sinnvoll - wenn man vor hat, dass nie ein Mensch die Dateien ansieht, sind Textdateien im Grunde genommen nutzlos und man wäre mit einem robusten Binärformat viel viel besser bedient.
Und statt normale Text-Dateien etwas wie JSON oder XML zu benutzen, hat den Vorteil, dass Parser einfach schon fertig sind. Du kannst mit 2 Zeilen irgendeinen Eintrag aus einer Datei holen, obwohl die vielleicht sehr kompliziert aufgebaut ist. Sobald du aber anfängst, den Standard zu ändern, hast du im Grunde genommen eine ganz andere Datei und sämtliche existierenden Parser sind nutzlos. Das hätte den selben Effekt, als würdest du dir einfach eine komplett neue Syntax ausdenken und parsen. Das kann man, wie gesagt, natürlich machen, aber man verliert dadurch halt einen wesentlichen Vorteil.

[Chromanoid]

Ich stimme Jonathan zu. Es geht doch gerade darum standardkonform zu sein, dann wird man auch durch IDEs unterstützt und wenn man an verteilten Systemen mit unterschiedlichen Programmiersprachen arbeitet gibt's schon das Datenprotokoll inkl. Parser.
Für Kommentare soll man laut Erfinder (@waigie dort steht auch warum keine Kommentare eingebaut wurden) das Zeug vor dem Parsen einfach durch (s)einen JavaScript-Minimizer jagen. Finde ich keine schlechte Idee, da man so im Grunde trotzdem standardkonform bleibt (dieses Mal halt der JavaScript-Standard), was wieder IDE-Unterstützung bedeutet.

[waigie]

@Chromanoid: Vielen dank für die Links. Jetzt ist mir klar warum JSON keine Kommentare unterstützt und zusammen mit JSmin lässt sich die Limitierung ja wirklich sinnvoll umgehen.