3 ms·

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while J

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround. Of course that's often not an issue, but I've run into it in the past. :)

taeric 8y ago
Oddly, attributes do little to actually help you here. What mattered was that xml gave you a language that could describe a valid document. Which, for reasons that actually exist, wasn't necessarily a valid xml document. That said, the effort to write a valid schema was rather high. And it was sold with the other technologies that were in violation of the anti-fragile spirit of the web. That left us with people wanting something different. JSON was born as much for basically being javascript literals minus functions as it was anything else. Most any other explanation is just someone selling you something. (Now, attributes did offer a technical way to ignore subsets of the attributes that would be hard to do any other way. But they didn't exactly make it easy, and namespaces did not compose nearly as well as people hoped they would.)
- tannhaeuser 8y ago
  JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.
  - taeric 8y ago
    I don't know what genesis myth you mean. I do know that I was regularly serializing JavaScript literals for years before I heard of json. Basically just said I could no longer serialize functions. Or references. Which, to be fair, was not that common and I could easily live without. I do miss being able to have comments.
tannhaeuser 8y ago
It's funny how people often compare JSON and XML, but fail to see that XML/SGML is for document data (like whole web pages) whereas JSON is a clever reuse of JavaScript object literal syntax.
ubernostrum 8y ago
http://www.flightlab.com/~joe/sgml/faq-not.txt http://www.flightlab.com/~joe/sgml/faq-not.txt Q. I'm designing my first DTD. Should I use elements or attributes to store data? A. Of course. What else would you use? Q. What is the usual way to choose between using attributes and children? [Update from David Carlisle:] In England, the normal method is to flip a coin in the air and call heads it's attributes, tails it's children. Unfortunately I'm not sure what to suggest in other countries where you can't guarantee having the Queen's head on one side of every coin.
- tannhaeuser 8y ago
  Hilarious, but the deeper rule is: when there isn't a concept of rendering a document to the user (where attributes hold rendering properties not directly presented to a user) the concept of a markup language doesn't make sense in the first place. So if you find yourself in a situation where you need to decide on encoding data as elements vs attributes, you probably shouldn't use SGML/XML at all. But then there is the wealth of XML standard data representations for financial/fiscal/e-commerce, medical, etc. data. You're deciding to use them to have your interfaces being implemented once and for all, and be able to switch eg. payment providers by merely specifying new endpoints and credentials. JSON doesn't really compare to XML/XSD in this space.

taeric 8y ago

Oddly, attributes do little to actually help you here. What mattered was that xml gave you a language that could describe a valid document. Which, for reasons that actually exist, wasn't necessarily a valid xml document. That said, the effort to write a valid schema was rather high. And it was sold with the other technologies that were in violation of the anti-fragile spirit of the web. That left us with people wanting something different. JSON was born as much for basically being javascript literals minus functions as it was anything else. Most any other explanation is just someone selling you something. (Now, attributes did offer a technical way to ignore subsets of the attributes that would be hard to do any other way. But they didn't exactly make it easy, and namespaces did not compose nearly as well as people hoped they would.)

tannhaeuser 8y ago
JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.
- taeric 8y ago
  I don't know what genesis myth you mean. I do know that I was regularly serializing JavaScript literals for years before I heard of json. Basically just said I could no longer serialize functions. Or references. Which, to be fair, was not that common and I could easily live without. I do miss being able to have comments.

tannhaeuser 8y ago

It's funny how people often compare JSON and XML, but fail to see that XML/SGML is for document data (like whole web pages) whereas JSON is a clever reuse of JavaScript object literal syntax.

ubernostrum 8y ago

http://www.flightlab.com/~joe/sgml/faq-not.txt http://www.flightlab.com/~joe/sgml/faq-not.txt Q. I'm designing my first DTD. Should I use elements or attributes to store data? A. Of course. What else would you use? Q. What is the usual way to choose between using attributes and children? [Update from David Carlisle:] In England, the normal method is to flip a coin in the air and call heads it's attributes, tails it's children. Unfortunately I'm not sure what to suggest in other countries where you can't guarantee having the Queen's head on one side of every coin.

tannhaeuser 8y ago
Hilarious, but the deeper rule is: when there isn't a concept of rendering a document to the user (where attributes hold rendering properties not directly presented to a user) the concept of a markup language doesn't make sense in the first place. So if you find yourself in a situation where you need to decide on encoding data as elements vs attributes, you probably shouldn't use SGML/XML at all. But then there is the wealth of XML standard data representations for financial/fiscal/e-commerce, medical, etc. data. You're deciding to use them to have your interfaces being implemented once and for all, and be able to switch eg. payment providers by merely specifying new endpoints and credentials. JSON doesn't really compare to XML/XSD in this space.