7 ms·
XML: Contrary to popular belief, it doesn't always kill babies
- snprbob86 16y agoI have a strict NO XML policy in any codebase that I control. 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. That said, XML has killed every baby I've ever exposed to it.
- bpodgursky 16y agoDo you count even things like ant buildfiles? I won't say that editing them is fun, but it's no worse than configuring any other build system.
- beagle3 16y agoWell, Java is worse than most things, but even for Java - djb redo, recently implemented by Avery Pennarun (apenwarr) is better than everything else.
- endtime 16y agoIf you're using Java, you've already given up on not killing babies.
- beagle3 16y agoWell, Java is worse than most things, but even for Java - djb redo, recently implemented by Avery Pennarun (apenwarr) is better than everything else.
- xiongchiamiov 16y agoReally? In my (admittedly limited) experience, ant was much more of a PITA than things like Rake and Scons.
- beej71 16y agoI've exposed it to the "structured document markup" baby, and it has cared for it quite nicely.
- zdw 16y agoDoes this go along with your strict "NO WINDOWS" and "NO FUN" policies as well? Seriously, there are places where XML is the right tool, which the poster does a fine job of bringing up. There are a lot of places where it is not, but was used because something better for those specific use cases hadn't been invented yet - JSON is barely 10 years old, whereas XML's SGML roots go back over 30. Whatever the case, we're better off with ANY structured data format than old delimited and fixed column width formats from the dinosaur days.
- udp 16y agoNicely unbiased. Not sure about the title, though, since the article is (quite rightly) more about why not to use XML.
- deleted 16y ago[deleted]
- krig 16y ago> 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. I don't know if unparallelled failure is a good indicator of design ability... 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? My personal opinion is that XML always kills the baby, and nothing I've experienced has made me reconsider that assessment.
- fedd 16y agowill someone write that java or at least jvm doesn't kill babies? 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!.. i think the main thing is not be religious about formats.
- bpodgursky 16y agoIf they're dumb enough to judge the innovativeness of software based on something like that, their opinion is probably irrelevant.
- wallflower 16y agoJava has won. It is the COBOL of our generation. The reason why people hate Java is because they don't want to be programming Java - they want to be coding in something cooler. But the thing is, trendy doesn't necessarily equate to stability.
- DjDarkman 16y ago> Computers adore XML. It's nice and easy to parse, so structured and precise. Computers love that shit. 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. There may be good tools for this, but I wouldn't call parsing it easy especially compared to other formats out there.
- _delirium 16y agoThe fact that you can't parse it with standard parsing tools doesn't seem like a win on the parseability front either. Not its biggest problem, but nothing in this use-case made it necessary to define a syntax that tools like lex/yacc can't parse. The core problem is that matching up start/end tags can't be done in a context-free language unless there are a finite number of tags (it's isomorphic to the problem of checking for palindromes). You'd need a parser-generator that lets you do backreferences (which makes it not context-free), so you could write a definition along the lines of: element = '<' + element_name + '>' + element + '</' + $1 + '>' | nil Either that, or a hand-rolled parser, which is in practice what XML parsers are.
- Homunculiheaded 16y agoThe more I work with XML, the more I'm convinced that Naggum was dead on: http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html 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.
- andolanra 16y ago"The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." —Philip Wadler, "The Essence of XML," presented at POPL 2003 And he knows what he was talking about—he was one of the people who worked on XQuery, after all.
- billsix 16y agoA quote of his: "XML is a giant step in no direction at all"
- Groxx 16y ago>There just isn't a really nice way to represent a tree structure in something like JSON. What? They're trivially identical! Here, an algorithm to convert from XML to JSON: < => { > => } attribute="value" => key:"value" contents => $:[{},"",{},etc,"look ma, multiple text nodes!"] node name => #:"name" Actually, there's one that most JSON parsers can do that XML can't: key: function(){alert("Oh joy, someone used <em>eval!</em>");} => ??? edit: thought of another one: {"spaces in <key name{w00t}>":value} => ? I have absolutely no idea 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: http://tools.ietf.org/html/draft-zyp-json-schema-03 http://tools.ietf.org/html/draft-zyp-json-schema-03 , or a pre-defined set of rules like JSON-RPC?), and XPath == CSS-like selectors with a different set of characters. 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 tons 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). 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.
- Homunculiheaded 16y agoI once explored the topic of "xml is just verbose s-exps" with someone who had no lisp experience. His first response was that it would be impossible to just use lisp in place of xml because you would then have to implement a minimal lisp parser into any language that wanted to make use of data stored in s-exps. I then pointed out that you have to do the same thing for xml or json, it's just that we've become used to standard tools existing to do this. That's actually where I find that XML is the most dangerous. People just take it as a fact of the universe that XML exists and make so many assumptions about how it solves a particular problem that they don't even stop to think "could there be a better way?"
- 16y ago
- nivertech 16y agoFor somebody who want to make XML shorter and more human-readable: 1. Use more attributes, i.e.: <employee first="Steve" last="Jobs/> instead of <employee> <first>Steve</first> <last>Jobs</last> </employee> 2. Use Camel case instead of '_', i.e.: <MyElementName>XXX</MyElementName> instead of: <my_element_name>XXX</my_element_name> 3. Use sane namespace prefixes. 4. Write XSD schema (or generate it from example XML document) - Tools like XMLSpy really helpfull in filling complex XMLs.
- Groxx 16y ago1 is a good example of something I see people doing wrong with XML on a regular basis. If there can't be a list of items, it should be an attribute, not a node.
- nivertech 16y agoActually it's abuse of attributes, since attributes must be metadata only, while data itself should be in element content. But it makes large XML files much more readable ...
- Groxx 16y agoOnly because you don't tend to find XML tidiers that display like this: <node_name attr="value" attr2="value2"> always this: <node_name attr="value" attr2="value2" etc="etc" ad="infinitum" until="you have to scroll"> edit: On a <person>, how do you define what's data and what's metadata? Is a name data or metadata? What's the difference between data and metadata in the first place, in a concrete, testable definition? Google define:metadata says: data about data; "a library catalog is metadata because it describes publications" So a library catalog should be like this? <library name="of congress" 978_3_16_148410_0="<data title=\"\">contents</data>" 978_3_16_148410_1="<data title=\"\">contents</data>" etc > (intentionally reducto-ad-absurdum)
- cperciva 16y agoSome of us find unix_style names far more readable than CamelCase. Underscores are almost spaces and make it much easier to recognize where each word starts.
- jister 16y agoTechnologies has its pros and cons so yeah, XML when used properly, doesn't kill babies.
- orls 16y ago"When your only tool is XML, every problem looks like it's a schema declaration and a few XSLT transformations away from a nail" 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 almost every problem as solvable with XML/XSLT, and pushes it one his teams. 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...
- contextfree 16y agoFive 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.
- TeMPOraL 16y agoIn 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.