3 ms·

In 10 years we will see JSON with the same mix of mockery and regret as we see XML today.

scrollaway 6y ago
I remember reading that opinion 10 years ago.
seagreen 6y ago
Just curious-- have you actually read the specifications for both? The difference in length and complexity is like this comment vs. War and Peace.
atarian 6y ago
If another standard were to dethrone JSON, my guess would be YAML.
- timw4mail 6y ago
  Considering that the YAML spec rivals XML in complexity, I doubt it. Between that complexity, incompatible parsers, intentional loose types...what do you really gain?
- jniedrauer 6y ago
  YAML will never be a sane format for machines to talk to each other. There are just too many ways to interpret it. It's not even really a good human-readable format. Maybe something like TOML? It's very human-readable and simple. But it's not a very good serialization language.
wvenable 6y ago
I remember using XML-RPC back in the day to communicate between a desktop client and a web service. It was fantastic. And then designer went off with a committee somewhere and produced SOAP. The regret with XML is that it continued to evolve into a monstrosity. Thankfully JSON came along and got back to the simplicity of early XML and XML-RPC and stayed there.
- user5994461 6y ago
  I remember killing some old XML-RPC applications. Deserialization and remote code execution vulnerabilities all over the place. That was brutal. Who thought this was a good idea to pass arbitrary function names and arguments for the remote servers to resolve and execute blindly? The regular vulnerabilities in the XML parsing libraries themselves was the nice cherry on top.
  - wvenable 6y ago
    > for the remote servers to resolve and execute blindly I'm not sure who would would to that but I certainly didn't. Ultimately XML-RPC is no different from REST/JSON except it's in a different format. What you did with that format is a totally different issue.
    - user5994461 6y ago
      Just take the first example from wikipedia: <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>40</i4></value> </param> </params> </methodCall> The thing is meant to call arbitrary functions with arbitrary arguments. It doesn't take long until there is a straight up exec functions exposed or some accidental command injection. It's strange to look at it 20 years later. The adoption of JSON really got developers to stop shipping RCE vulnerabilities every other week. Yet nobody must have thought of that when deciding what to use.
      - wvenable 6y ago
        What do you think happens with REST and JSON? Or SOAP? This is exactly identical to: { "methodName": example.getStateName "params": [14] } Although you'd probably instead have an REST endpoint contain the method name and the entire JSON body is the parameters. But the difference is minor. There's no reason this allows arbitrary execution than anything else. Methods directly exposed to the web is how 99% of all MVC frameworks work.
- 6y ago

I remember reading that opinion 10 years ago.

Just curious-- have you actually read the specifications for both? The difference in length and complexity is like this comment vs. War and Peace.

atarian 6y ago

If another standard were to dethrone JSON, my guess would be YAML.

timw4mail 6y ago
Considering that the YAML spec rivals XML in complexity, I doubt it. Between that complexity, incompatible parsers, intentional loose types...what do you really gain?
jniedrauer 6y ago
YAML will never be a sane format for machines to talk to each other. There are just too many ways to interpret it. It's not even really a good human-readable format. Maybe something like TOML? It's very human-readable and simple. But it's not a very good serialization language.

wvenable 6y ago

I remember using XML-RPC back in the day to communicate between a desktop client and a web service. It was fantastic. And then designer went off with a committee somewhere and produced SOAP. The regret with XML is that it continued to evolve into a monstrosity. Thankfully JSON came along and got back to the simplicity of early XML and XML-RPC and stayed there.

user5994461 6y ago
I remember killing some old XML-RPC applications. Deserialization and remote code execution vulnerabilities all over the place. That was brutal. Who thought this was a good idea to pass arbitrary function names and arguments for the remote servers to resolve and execute blindly? The regular vulnerabilities in the XML parsing libraries themselves was the nice cherry on top.
- wvenable 6y ago
  > for the remote servers to resolve and execute blindly I'm not sure who would would to that but I certainly didn't. Ultimately XML-RPC is no different from REST/JSON except it's in a different format. What you did with that format is a totally different issue.
  - user5994461 6y ago
    Just take the first example from wikipedia: <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>40</i4></value> </param> </params> </methodCall> The thing is meant to call arbitrary functions with arbitrary arguments. It doesn't take long until there is a straight up exec functions exposed or some accidental command injection. It's strange to look at it 20 years later. The adoption of JSON really got developers to stop shipping RCE vulnerabilities every other week. Yet nobody must have thought of that when deciding what to use.
    - wvenable 6y ago
      What do you think happens with REST and JSON? Or SOAP? This is exactly identical to: { "methodName": example.getStateName "params": [14] } Although you'd probably instead have an REST endpoint contain the method name and the entire JSON body is the parameters. But the difference is minor. There's no reason this allows arbitrary execution than anything else. Methods directly exposed to the web is how 99% of all MVC frameworks work.
6y ago