5 ms·

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 sec

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.

famousactress 13y ago
...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).
kasbah 13y ago
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/master/Symbol_Attention_CopperTop_Big.kicad_mod https://github.com/KiCad/Footprint_Symbols.pretty/blob/maste...
- peq 13y ago
  Are S-Expressions a standardized data format? It looks very similar to Json, but harder to read.
  - kasbah 13y ago
    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 https://en.wikipedia.org/wiki/S-expression#Standardization
patrickmay 13y ago
s-expressions (http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions) are another option. Even people who prefer JSON recognize the advantages: http://irreal.org/blog/?p=713 http://irreal.org/blog/?p=713
- barrkel 13y ago
  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.
  - andrewflnr 13y ago
    What on earth is the problem with (dict (key1 value1) (key2 value2))? I would render {people: ["joe", "bob"]} as (dict (people (list "joe" "bob"))).
rdtsc 13y ago
> I don't want to look at binary data responses. 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.
- alecthomas 13y ago
  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.
  - nawitus 13y ago
    But that's a special case. Most JSON messages are probably short enough to read without a special tool.
  - nknighthb 13y ago
    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.
craigching 13y ago
> The only three formats I've found so far that are readable and well supported 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.
mwcampbell 13y ago
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.
- pg_is_a_butt 13y ago
  i always just look at it. i could just as easily do the same with MessagePack or BERT and see nothing of use.
draegtun 13y ago
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 http://www.rebol.com/cgi-bin/blog.r?view=0522 (HN - https://news.ycombinator.com/item?id=5654895 https://news.ycombinator.com/item?id=5654895)

famousactress 13y ago

...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).

kasbah 13y ago

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/master/Symbol_Attention_CopperTop_Big.kicad_mod https://github.com/KiCad/Footprint_Symbols.pretty/blob/maste...

peq 13y ago
Are S-Expressions a standardized data format? It looks very similar to Json, but harder to read.
- kasbah 13y ago
  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 https://en.wikipedia.org/wiki/S-expression#Standardization

patrickmay 13y ago

s-expressions (http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions) are another option. Even people who prefer JSON recognize the advantages: http://irreal.org/blog/?p=713 http://irreal.org/blog/?p=713

barrkel 13y ago
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.
- andrewflnr 13y ago
  What on earth is the problem with (dict (key1 value1) (key2 value2))? I would render {people: ["joe", "bob"]} as (dict (people (list "joe" "bob"))).

rdtsc 13y ago

> I don't want to look at binary data responses. 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.

alecthomas 13y ago
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.
- nawitus 13y ago
  But that's a special case. Most JSON messages are probably short enough to read without a special tool.
- nknighthb 13y ago
  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.

craigching 13y ago

> The only three formats I've found so far that are readable and well supported 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.

mwcampbell 13y ago

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.

pg_is_a_butt 13y ago
i always just look at it. i could just as easily do the same with MessagePack or BERT and see nothing of use.

draegtun 13y ago

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 http://www.rebol.com/cgi-bin/blog.r?view=0522 (HN - https://news.ycombinator.com/item?id=5654895 https://news.ycombinator.com/item?id=5654895)