Hmm. I'm disappointed to see the article getting voted up but I suppose that fairly reflects a certain amount of widespread frustration with XML. As a standar

Hmm. I'm disappointed to see the article getting voted up but I suppose that fairly reflects a certain amount of widespread frustration with XML. As a standard, XML is actually pretty simple and, in my opinion, well thought out. Alas, freely available high quality documentation to take someone from 0 knowledge to a good grasp appears to be lacking. Many tools which claim to process XML are poorly written. The author's list of complaints and some responses: * "XML is very bad at handling binary data." That is mostly false. There is no obviously winner (widely adopted) standard for binary format XML although there will be some day. At that time, XML will be the best choice for new binary file formats and, I predict, processors for many legacy binary formats will gain DOM-based APIs. The surface syntax of textual XML requires that binary data be encoded into a safe character set. That's actually important for data interchange. * "XML is incredibly verbose." Yes, yes it is. The primary sources of apparently needless verbosity are first, the need to mention the element name in closing end tags ("</foo>") and, second, the need to always wrap element names and closing tags (and attributes) in "<...>" pairs. The parent language (SGML) had mechanisms to relax those constraints and yield a more compact syntax. These were dropped in XML (for now) to make it easier to write parsers by getting the general case working first. Perhaps over time we will reintroduce a more flexible syntax or perhaps we'll discover we don't need it much. * "DTDs use different syntax." That is a complaint about DTDs, not XML. Some schema languages use XML syntax and, as I recall, there is an XML syntax for DTDs. This complaint is mis-directed. * "Confuses meta-data with content. Sometimes XML attributes contain values other times the value is in XML text." This statement is inaccurate and betrays the authors poor understanding of XML (see above about the poor state of XML documentation). Sometimes data is placed in element attributes and other times data is placed in XML sub-elements (not necessarily "text"). An XML datum is an inductively defined finite tree structure. Leaf nodes may contain text or more shallow trees. Leaf nodes are labeled with a type tag - the element name. The type of a node is parametric - it has parameters. Those parameters are element attributes. Generally speaking, if you have data that tells you something about the contents of an element, or about how to interpret the element - it goes in attributes. Otherwise, it goes into sub-elements. A good criticism of XML would be that currently, attribute values may not be arbitrary XML datums - but there is nothing in the definition of XML that prevents fixing this in the future. * "Unclear use of whitespace. Should a carriage-return after a tag be ignored? Should tabs be ignored?" This statement betrays the author's poor understanding of XML (see above about the poor state of XML documentation). In fact, XML specifications state two things that lead to the author's confusion, and some XML-based tools do confusing third things. (1) XML specifies a precise and simple canonicalization of whitespace. (2) XML specifies how to handle whitespace in tools which are manipulating XML source code rather than manipulating the canonical form. (3) Some tools do random, ad-hoc things - these are bad tools. * "XML tools/libraries are very bad. The standard Java libraries have come a long way, but DOM parsing is still a chore." Many tools and libraries are very bad, some our wonderfully good. Because the author has a poor understanding of XML (see above about the poor state of XML documentation) he is not able to quickly tell the good tools from the bad and so the whole field looks to him a mess. I sympathize with the author quite a bit but if he understood XML better and stuck to good tools, his only complaint would be that there aren't enough good tools yet (though there are quite a few and you can get quite far with just what's already there). The author complains: "XML has so many problems that an endless series of patches have been pasted on it. Each patch, however, has made XML worse: CDATA, namespaces, etc." I am fairly certain that it is historically inaccurate to describe namespaces or CDATA as "patches pasted on". Namespaces are, in fact, one of the great strengths of XML. The real problem is that too many programmers making use of XML don't understand them and therefore fail to use them or fail to use them properly (see above about the poor state of XML documentation). XML namespaces create a cooperative way to allocate element and attribute names in a distributed and decentralized way without introducing any central authorities not already present in the allocation of URLs. In this way, XML element names are vastly superior to lisp atom (symbol) names for tagging tree nodes and attribute names. Namespaces are one of the more important advances that XML represents. I have less of a defense for CDATA but not no defense at all. On one level it is a handy addition to XML surface syntax. At the DOM level, it helps preserve the ability to reasonably "pretty-print" an XML datum. It is a bit ad hoc but it causes very little harm and is often enough quite convenient. The author opines: "It was clear to me when XML first came on the scene that it was a bad specification for data interchange. How it came to be so widely used is a mystery to me. The most plausible explanation is that XML became a means for Microsoft, Sun, Oracle, et al to attempt to wield control over the industry. Each company used XML as a basis for creating semi-proprietary protocols that they could control." XML has been adopted by far more players than Microsoft, Sun, and Oracle and is used by some quite excellent free software products. So many very talented programmers and teams have chosen XML that the author should consider applying Occam's razor and the scientific method here. A simpler explanation than his conspiracy theory is that the author's judgement that XML is a bad format is a mistaken judgement. (See above about the poor state of XML documentation.) Finally, the author concludes: "The industry appears to be moving away from XML [....]" From where I sit, he is profoundly mistaken. Javascript toolkit authors and similar have often moved to JSON and similar, for temporary convenience, but in many other domains XML continues to make slow and steady advances, receiving huge amounts of investments. I really, really do not want anything I've said above to be taken as a criticism of the author's person or skills. I don't mean to say that he is professionally wrong to shy away from XML in his own work. (See above about the poor state of XML documentation (and many tools).) His report is interesting as a reflection of frustrations that people in some domains are feeling. It's just mostly wrong on mostly every point (but for understandable reasons).