><i>There just isn't a really nice way to represent a tree structure in something like JSON.</i><p><i>What</i>? They're trivially identical! Here, an algorithm to convert from XML to JSON:<p><pre><code> < => {
> => }
attribute="value" => key:"value"
contents => $:[{},"",{},etc,"look ma, multiple text nodes!"]
node name => #:"name"
</code></pre>
Actually, there's one that most JSON parsers can do that XML can't:<p><pre><code> key: function(){alert("Oh joy, someone used <em>eval!</em>");} => ???
</code></pre>
edit: thought of another one:<p><pre><code> {"spaces in <key name{w00t}>":value} => ?
</code></pre>
I have absolutely <i>no idea</i> how people come to the conclusion that XML somehow magically does X while nothing else does. XSLT can be modified to work on JSON, schema definitions too (how about: <a href="http://tools.ietf.org/html/draft-zyp-json-schema-03" rel="nofollow">http://tools.ietf.org/html/draft-zyp-json-schema-03</a> , or a pre-defined set of rules like JSON-RPC?), and XPath == CSS-like selectors with a different set of characters.<p>The only difference between XML and JSON is the character set and the tool-chains available. JSON is rapidly gaining the same capabilities through tools, while XML has <i>tons</i> of non-compliant libraries (I've had to deal with other people's XML APIs in cases where attribute order mattered (likely hand-rolled, I know), or they couldn't parse a standard schema doc, or they couldn't handle namespaces properly).<p>About the only thing you can say is that JSON is XML "lite", currently, and is a new chance to do things differently / correctly. The problems many people have with XML relates to just that - non-compliant libraries that clog the XML tubes, making working with it a total crap-shoot often enough that it's worth avoiding.
I have a strict NO XML policy in any codebase that I control.<p>It's not because I think that XML necessarily always kills babies, it's because I think that XML has never once been the best choice. "Does everything well enough, but I don't need to learn or develop a new technology" is not a valid reason to use it and there are plenty of valid reasons not to use it.<p>That said, XML has killed every baby I've ever exposed to it.
> Computers adore XML. It's nice and easy to parse, so structured and precise. Computers love that shit.<p>It's not the easy to parse, without interpreting complex schemas that are sometimes missing. It's not even easy to map, you have the attributes, the children and inner text, this makes it a pain to map to native objects.<p>There may be good tools for this, but I wouldn't call parsing it easy especially compared to other formats out there.
The more I work with XML, the more I'm convinced that Naggum was dead on:
<a href="http://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">http://www.schnada.de/grapt/eriknaggum-xmlrant.html</a><p>XML is, for me, the classic example of the problem of reinventing things badly. The sad thing is that we've barely been programming for 60 years and we've already reached the point where much of our work is wasted in this process.
> Microsoft might not be totally crazy for basing their docx file format on XML. Honestly, I'd expect them to be uniquely qualified by years of hindsight, shame, and regret to design a document format.<p>I don't know if unparallelled failure is a good indicator of design ability...<p>It's amusing though, pretty much the only area where the article actually claims XML doesn't kill babies is in representing trees. Ehm, how about sexprs for hierarchial data representation?<p>My personal opinion is that XML <i>always</i> kills the baby, and nothing I've experienced has made me reconsider that assessment.
For somebody who want to make XML shorter and more human-readable:<p>1. Use more attributes, i.e.:<p><pre><code> <employee first="Steve" last="Jobs/>
</code></pre>
instead of<p><pre><code> <employee>
<first>Steve</first>
<last>Jobs</last>
</employee>
</code></pre>
2. Use Camel case instead of '_', i.e.:<p><pre><code> <MyElementName>XXX</MyElementName>
</code></pre>
instead of:<p><pre><code> <my_element_name>XXX</my_element_name>
</code></pre>
3. Use sane namespace prefixes.<p>4. Write XSD schema (or generate it from example XML document) - Tools like XMLSpy really helpfull in filling complex XMLs.
will someone write that java or at least jvm doesn't kill babies?<p>i remember how someone saw an xml config in my java-based software demo and judged it's innovatiiveness based on it. and it was not even mine, it was standard web.xml!..<p>i think the main thing is not be religious about formats.
"When your only tool is XML, every problem looks like it's a schema declaration and a few XSLT transformations away from a nail"<p>This almost exactly describes a Project Manager I've worked with -- he has had experience with a CMS system that was entirely XML-document based, and sees <i>almost every</i> problem as solvable with XML/XSLT, and pushes it one his teams.<p>Which is a good example of why project managers shouldn't be allowed (or at least not depended on) to make technical architecture decisions. We've ended up doing a giant site search project based on huge XML indexes...
Five years ago I was a hardcore XML-hater (and an even more hardcore SOAP/WS-* hater), but these days I've sort of become an apologist for both. Not that XML has gotten any less ugly, I'm just annoyed at people mistaking superficial problems with deep problems, and start over every five years or so with a new syntax or something thinking it'll make those deep problems go away.
In what way "computers adore XML"? Well, it can represent trees (and so can S-expressions), but its verboseness makes the files bigger, parsing more computation-intensive and memory consuming.