The first requirement that I look for in a data interchange format is that it should be readable, because I don't want to look at binary data responses. The second thing I look at is support for encoding and decoding it.
The only three formats I've found so far that are readable and well supported are XML, JSON, and YAML. XML is too hefty and wasteful. YAML has had a bad history of insecure encoders and decoders but overall is my favorite data format. However, it still has the downside of needing a special decoder since browsers don't support it, and it requires specific indentation for its hierarchical data format which is wasteful in its own way.
That just leaves JSON in my opinion. It's easily understood and read, and native browser and Node.js encoding and decoding is more than fast enough.
I've always found this pretty semantic. Obviously tool support for reading ascii or UTF-8 encoded text is very strong, but it's all binary, so it's a question of tools. I do find JSON the most palatable of the text-encoded formats, but I'd adore it if a solid binary replacement gained favor. Unfortunately I think a lot of the protocols that have had pretty good energy behind them (pbuffers, thrift, hessian, etc.) end up either going the compiled-stubs route ,or bundle RPC, or both.
I'd really like to see a binary protocol with solid type support (please God, let it define a built-in datetime) that can be written and read dynamically (without a header file/stub).
I always use "python -m json.tool" to pretty-print JSON data before looking at it. I could just as easily do the same with a MessagePack or BERT pretty-printer.
Agreed. And further to this, unless the JSON is indented for humans (not common) you still need a tool to format it. So if you're using a tool anyway, you could just as easily have used a binary format.
The largest JSON file I ever dealt with was a few megabytes. 99% or more of JSON I deal with is well under a kilobyte. The vast majority is no more than a few hundred bytes.
Can I easily copy and paste a binary format between text editors and emails and IM? Can I easily write that binary format by hand?
If your answer is "just transform it to/from JSON", I ask this: Why bother, then, since JSON itself works just fine, and avoids unnecessary layers?
With JSON, I get something that can be both read by a human and processed a computer with a minimum of translation and abstraction. I know exactly what is happening every step of the way, and can trivially verify what data is being passed around by analyzing logs, sniffing network packets, and even delving into memory dumps.
I don't think you've dealt with JSON enough. I live and breathe JSON. It is the lingua franca binding together a couple dozen developers working on seven different services written in six different languages (including, incidentally, erlang, which certainly wasn't my idea), and myriad client implementations in at least as many languages and even more runtimes on a dozen different platforms. (And these numbers are actively growing.)
We could not work with a binary format. This is a matter of practicality. There are developers of every skill set and experience level involved, there are third-parties involved (including those with strict control over some platforms that severely limit what kinds of code we can run), there are even customer-service reps involved who see this stuff.
JSON is easy to parse even in languages that make binary data difficult to deal with. It's easy for humans, wizard and muggle alike, to both read and create. As a text format it interacts well with the existing tools the entire world uses on their computers every day.
To say we should just use a binary format because we could conceivably spend time writing new, less-integrated, less-convenient tools to work around the problems it gives us is to miss the forest for the trees. We don't need better performance, and we've got enough problems to deal with without creating more.
I find it easier to read. It's easier to parse too so it doesn't rely on standardization as much. There was some effort towards standardization but nothing became of it.
Sexprs are (usually) node-labeled trees (xml is too), while json describes edge-labeled trees. Object-oriented data structures are edge-labeled graphs. Json is a slightly better fit for the most common implementation languages.
The page you linked to doesn't support your argument, BTW. It tries to assert that sexprs support hashes - by extending the syntax with a reader macro!
This line shows the author's confusion: "S-expressions are more powerful (because of the duality of code and data)". The guy is confusing a format that strictly should not have behaviour beyond constructing a data structure, with Lisp more generally. If you allow the data structure to contain code that further interprets the data structure, the complexity of sanitizing input greatly increases.
Let me also add Rebol into the mix. To quote Carl Sassenrath...
Every time I run across JSON examples, I see REBOL without the elegance. The two languages are related of course. REBOL strongly influenced the design of JSON.
Comments
The first requirement that I look for in a data interchange format is that it should be readable, because I don't want to look at binary data responses. The second thing I look at is support for encoding and decoding it.
The only three formats I've found so far that are readable and well supported are XML, JSON, and YAML. XML is too hefty and wasteful. YAML has had a bad history of insecure encoders and decoders but overall is my favorite data format. However, it still has the downside of needing a special decoder since browsers don't support it, and it requires specific indentation for its hierarchical data format which is wasteful in its own way.
That just leaves JSON in my opinion. It's easily understood and read, and native browser and Node.js encoding and decoding is more than fast enough.
...I don't want to look at binary data responses
I've always found this pretty semantic. Obviously tool support for reading ascii or UTF-8 encoded text is very strong, but it's all binary, so it's a question of tools. I do find JSON the most palatable of the text-encoded formats, but I'd adore it if a solid binary replacement gained favor. Unfortunately I think a lot of the protocols that have had pretty good energy behind them (pbuffers, thrift, hessian, etc.) end up either going the compiled-stubs route ,or bundle RPC, or both.
I'd really like to see a binary protocol with solid type support (please God, let it define a built-in datetime) that can be written and read dynamically (without a header file/stub).
I always use "python -m json.tool" to pretty-print JSON data before looking at it. I could just as easily do the same with a MessagePack or BERT pretty-printer.
I keep seeing this but having looked at hundred megabyte large JSON objects or XML files, some might as well be binary to my eyes.
Agreed. And further to this, unless the JSON is indented for humans (not common) you still need a tool to format it. So if you're using a tool anyway, you could just as easily have used a binary format.
The largest JSON file I ever dealt with was a few megabytes. 99% or more of JSON I deal with is well under a kilobyte. The vast majority is no more than a few hundred bytes.
Can I easily copy and paste a binary format between text editors and emails and IM? Can I easily write that binary format by hand?
If your answer is "just transform it to/from JSON", I ask this: Why bother, then, since JSON itself works just fine, and avoids unnecessary layers?
With JSON, I get something that can be both read by a human and processed a computer with a minimum of translation and abstraction. I know exactly what is happening every step of the way, and can trivially verify what data is being passed around by analyzing logs, sniffing network packets, and even delving into memory dumps.
I don't think you've dealt with JSON enough. I live and breathe JSON. It is the lingua franca binding together a couple dozen developers working on seven different services written in six different languages (including, incidentally, erlang, which certainly wasn't my idea), and myriad client implementations in at least as many languages and even more runtimes on a dozen different platforms. (And these numbers are actively growing.)
We could not work with a binary format. This is a matter of practicality. There are developers of every skill set and experience level involved, there are third-parties involved (including those with strict control over some platforms that severely limit what kinds of code we can run), there are even customer-service reps involved who see this stuff.
JSON is easy to parse even in languages that make binary data difficult to deal with. It's easy for humans, wizard and muggle alike, to both read and create. As a text format it interacts well with the existing tools the entire world uses on their computers every day.
To say we should just use a binary format because we could conceivably spend time writing new, less-integrated, less-convenient tools to work around the problems it gives us is to miss the forest for the trees. We don't need better performance, and we've got enough problems to deal with without creating more.
But that's a special case. Most JSON messages are probably short enough to read without a special tool.
What about S-Expressions? My electronics CAD program recently switched to using it for footprint and layout files and I am very happy about it. It looks like this in text: https://github.com/KiCad/Footprint_Symbols.pretty/blob/maste...
Are S-Expressions a standardized data format? It looks very similar to Json, but harder to read.
I find it easier to read. It's easier to parse too so it doesn't rely on standardization as much. There was some effort towards standardization but nothing became of it.
https://en.wikipedia.org/wiki/S-expression#Standardization
s-expressions (http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions) are another option. Even people who prefer JSON recognize the advantages: http://irreal.org/blog/?p=713
Sexprs are (usually) node-labeled trees (xml is too), while json describes edge-labeled trees. Object-oriented data structures are edge-labeled graphs. Json is a slightly better fit for the most common implementation languages.
The page you linked to doesn't support your argument, BTW. It tries to assert that sexprs support hashes - by extending the syntax with a reader macro!
This line shows the author's confusion: "S-expressions are more powerful (because of the duality of code and data)". The guy is confusing a format that strictly should not have behaviour beyond constructing a data structure, with Lisp more generally. If you allow the data structure to contain code that further interprets the data structure, the complexity of sanitizing input greatly increases.
What on earth is the problem with (dict (key1 value1) (key2 value2))? I would render {people: ["joe", "bob"]} as (dict (people (list "joe" "bob"))).
It probably doesn't fit your "well supported" criterion I suppose, but how about Clojure's EDN? I've been meaning to try it out more myself.
Let me also add Rebol into the mix. To quote Carl Sassenrath...
Every time I run across JSON examples, I see REBOL without the elegance. The two languages are related of course. REBOL strongly influenced the design of JSON.
ref: On JSON and REBOL - http://www.rebol.com/cgi-bin/blog.r?view=0522 (HN - https://news.ycombinator.com/item?id=5654895)