<story><title>In Defense of XML</title><url>https://blog.frankel.ch/defense-xml/</url></story><parent_chain><item><author>Tainnor</author><text>I&amp;#x27;m a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype.&lt;p&gt;Also the point about the ad-hoc client validation doesn&amp;#x27;t seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn&amp;#x27;t forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow.&lt;p&gt;My biggest gripes with XML are twofold:&lt;p&gt;- It&amp;#x27;s as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don&amp;#x27;t help).&lt;p&gt;- The community seems to have this obsession with solving every problem under the sun with more XML and more specifications. I believe, this is wrong. Trying to standardise across the whole range of data interchange and configuration needs is the wrong approach, IMHO. JSON wins here, because it gets out of the way. I do wish JSON had comments and that JSON schema was better (for when you really need it), but nobody ever had an expectation that keys are unique across all JSON documents in existence, something that XML somehow insists is necessary for its elements and attributes.&lt;p&gt;But what the author is right about is that YAML is an absolute nightmare, and I can&amp;#x27;t understand why it continues to be so popular. Apart from the dozens of ways of writing booleans or strings, it&amp;#x27;s also way, way too easy to forget what level of indentation you&amp;#x27;re currently at, especially if you&amp;#x27;re navigating large files like Kubernetes or CI configs.&lt;p&gt;I think more projects (at least larger ones) should adopt their own DSL for configuration. For example, I find the terraform config format much cleaner than any of the YAML stuff.</text></item></parent_chain><comment><author>Phrodo_00</author><text>My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it&amp;#x27;s not obvious which one to use. You can also use multiple child tags and it&amp;#x27;s not obvious whether you should mix multiple kinds or not.&lt;p&gt;The usage is obvious when using XML as markup, but when used for data it&amp;#x27;s left to the one creating the particular spec.&lt;p&gt;You can have style guidelines, but other data formats don&amp;#x27;t really need that to answer those questions. More flexible is not always better, especially in languages.</text></comment>
<story><title>In Defense of XML</title><url>https://blog.frankel.ch/defense-xml/</url></story><parent_chain><item><author>Tainnor</author><text>I&amp;#x27;m a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype.&lt;p&gt;Also the point about the ad-hoc client validation doesn&amp;#x27;t seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn&amp;#x27;t forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow.&lt;p&gt;My biggest gripes with XML are twofold:&lt;p&gt;- It&amp;#x27;s as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don&amp;#x27;t help).&lt;p&gt;- The community seems to have this obsession with solving every problem under the sun with more XML and more specifications. I believe, this is wrong. Trying to standardise across the whole range of data interchange and configuration needs is the wrong approach, IMHO. JSON wins here, because it gets out of the way. I do wish JSON had comments and that JSON schema was better (for when you really need it), but nobody ever had an expectation that keys are unique across all JSON documents in existence, something that XML somehow insists is necessary for its elements and attributes.&lt;p&gt;But what the author is right about is that YAML is an absolute nightmare, and I can&amp;#x27;t understand why it continues to be so popular. Apart from the dozens of ways of writing booleans or strings, it&amp;#x27;s also way, way too easy to forget what level of indentation you&amp;#x27;re currently at, especially if you&amp;#x27;re navigating large files like Kubernetes or CI configs.&lt;p&gt;I think more projects (at least larger ones) should adopt their own DSL for configuration. For example, I find the terraform config format much cleaner than any of the YAML stuff.</text></item></parent_chain><comment><author>kanox</author><text>The biggest advantage of JSON and YAML is that it has a very straight-forward object model consisting of literals, lists and dicts. All of these constructs map very easily to native data structures in most languages: you can just &amp;quot;load&amp;quot; and &amp;quot;save&amp;quot; an arbitrary json or yaml document.&lt;p&gt;The XML DOM is very different and does not map in an obvious way to objects in any programming language: you either use a DomDocument or object serialization for a subset of XML.&lt;p&gt;This alien object model makes programming with XML painful and verbose for no gain.&lt;p&gt;Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don&amp;#x27;t have to deal with elements and attributes. If standardization around YAML and XML was equally good would anyone pick XML?&lt;p&gt;&amp;gt; way too easy to forget what level of indentation you&amp;#x27;re currently at&lt;p&gt;This is easily solvable by tools. How is it worse than getting lost in braces or open&amp;#x2F;close tags?&lt;p&gt;&amp;gt; I think more projects (at least larger ones) should adopt their own DSL for configuration.&lt;p&gt;Please don&amp;#x27;t. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It&amp;#x27;s not much better than putting config consts in a code file.</text></comment>