XML is better than YAML – Hear me out
It&#x27;s an abuse of Ycombinator servers that I can&#x27;t paste a Billion Laughs statement that just fills up your parser with NONONONONONONONO for the next sixtillion eternities.<p>Because NONONONONONO . .<p>OK seriously. Seriously. These people all chillin&#x27; here in the future and talking about how great XML is need to jump in my DeLorean back to 2002. Or maybe try <i>using</i> XML for a few years. Or decades.<p><pre><code>  * Schemas break XML *all the time*[1], 
  * &quot;XML-aware&quot; diff&#x2F;merge[4], 
  * No Such Thing As Line Breaks[2],
  * Sneaky proprietary entities[3], 
  * NAMESPACES, 
  * &quot;1NF? Is that a sex thing?&quot;, 
  * Computability[4], 
  * FRICKIN CHARSETS, 
  * asemantic but pretends to have semantics, 
  * Hierarchy Fetishism
</code></pre>
And so so so much more. The combined effect of this is that it reduces the volume of the tool ecosystem for a given XML spec. Don&#x27;t believe me? Run the metrics on gitlab&#x2F;github&#x2F;npm&#x2F;pip&#x2F;DaSEA[5].<p>So the tool ecosystem is - very often - only as big as a singular project. It&#x27;s one of the reasons there&#x27;s so many XML editor vendors. In S1000D, it&#x27;s pretty common to have a <i>special vendor for each project</i>.<p>XML completely nukes, by its essential nature, any possibility of using standard tools. There is an entire category of emergent technology - Lightweight Markup Languages - that were invented, by individuals, working for free, for no other reason than to get out of XML.<p>Using XML at scale is something that should never happen, for any reason, ever. It&#x27;s this horrifying perfect storm of non-technical academics steering a crew of malcontents still angry at how GML went. Ol&#x27; Linus was a bit of a butthole, but he was right on the money when it came to XML. ALL of the problems YML has that are mentioned  - they can ALL be found in XML, but they&#x27;re magnified times fifty bazillion because of the inherent lack of support.<p>[1] Leading whitespace in attributes? HOW CHARMING. Yeah, that&#x27;s in a schema, a very popular one. So each schema is its own language, and both DITA and S1000D allow for virtually any level of customization on top of that, and on top of THAT, in S1000D, you have to contend with each of the Issues. Seriously, it&#x27;s a flashback to the pre-ATA100&#x2F;JASC 1930s &quot;shop manual&quot; systems.<p>[2] No such thing as &quot;normalized&quot; when it comes to XML whitespace, which means no lines, no tabs, no spaces. Everything is elements. Oh, ha ha, unless there&#x27;s dual-mode DTD&#x2F;XSD validation . . which should REALLY have its own bullet. Do you realize, in any way, how incredibly radioactive external entities in a internet-facing parser are?<p>[3] REVBARS! Oh, and FRICKIN CGMs. Good luck processing those, because they were golden tickets handed out to ISO-favored software vendors.<p>[4] Infinite arbitrary nesting combined with whitespace agnostic means it&#x27;s REALLY hard to make any sort of compute optimization unless you load the WHOLE thing into memory. An xml-aware git repository has performance several orders of magnitude worse than a normal one, and if used in quantity with goofball schemas, you can actually choke a Bitbucket CLI.<p>[5] <a href="https:&#x2F;&#x2F;dasea-project.github.io&#x2F;DASEA&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;dasea-project.github.io&#x2F;DASEA&#x2F;</a>