31–40 of 120 posts
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
Yeah, but the downside to doing that with XML is it's frickin crazy. I have to parse this whole thing into memory and then pull out the part I want? The CPU is spending more time dealing with XML than it is doing useful work. If it's a big file, this is very significant. In JSON, you get the same expressiveness without the hassle.
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
Yeah, but the downside to doing that with XML is it's frickin crazy. I have to parse this whole thing into memory and then pull out the part I want? The CPU is spending more time dealing with XML than it is doing useful work. If it's a big file, this is very significant. In JSON, you get the same expressiveness without the hassle.
You do that with JSON too, don't you? Are there SAX-like parsers for JSON?
If it's a big file it'll be big in JSON too.
So count me in. I'll use JSON over XML for server-webclient data exchange whenever I can. It's just much easier.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is, just as the article says, you have more degrees of freedom in how you represent your data, and what is a "degree of freedom" but a near synonym of "dimensionality"? You can't abstract around dimensionality very effectively without losing fundamental capabilities in the underlying component (in fact a staggering number of abstraction failures in general can be shown to come from exactly this problem if you really learn to think this way), and the complexity comes poking out in the XPath. It's still better than groveling over the DOM yourself, but it's probably also the absolute peak of concision that is obtainable; there will be nothing better.
JSON is indeed simpler in that you don't really have 3 or 4 feasible choices per attribute; {"first-name": "John", "last-name": "Smith"} is pretty much your choice, full stop. That leaves the underlying library fundamentally, not accidentally, simpler. This can get you into some trouble in some cases, for instance XML is a better choice for HTML-type tagged text as the JSON for tagged-text is just hideous (and, interestingly, reopens the dimensionality problem as there is no one obvious solution), but many things are fundamentally simpler than tagged-text.
If you want to pick up a defined serialization format, my gut would be to say to default to JSON and back to XML if you really need it for something... but be aware that you may, and it's no better to try to jam JSON on top of a fundamentally XML problem. (Besides, your JSON can carry bits of XML in it without much pain, so "best of both worlds" is perfectly feasible.)
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
I'm not sure if you are complaining about this aspect, but I would observe that "fewer options" is actually the feature here, not the bug. A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is,…
(Although I like it when my target web apps use XML; better tools support for attacking them.)
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
I've gotten the informal impression that incidental complexity (you know, complexity arising not from the problem but the solution) is a factor behind the hugeness of the XML ecosystem, but I'd be happy to learn otherwise...
As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.
Sorry we were late to the party, guys, we just got so wrapped up in writing software that people actually use.
Earlier quoted context omitted.
I'm not sure if you are complaining about this aspect, but I would observe that "fewer options" is actually the feature here, not the bug. A generic XML DOM is still complicated to deal with. Even if you do the "right thing" and use XPath, you still have to deal with XPath because you can't get around the fact that you have an underlying representation that has at least two dimensions (attributes vs. CDATA). That is,…
Whoah wait hold on a sec. I'm not sticking up for XML. I'm just saying that one argument isn't valid. I'd use JSON. (Although I like it when my target web apps use XML; better tools support for attacking them.)