It's an abuse of Ycombinator servers that I can't paste a Billion Laughs statement that just fills up your parser with NONONONONONONONO for the next sixtillion eternities.
Because NONONONONONO . .
OK seriously. Seriously. These people all chillin' here in the future and talking about how great XML is need to jump in my DeLorean back to 2002. Or maybe try using XML for a few years. Or decades.
* Schemas break XML *all the time*[1],
* "XML-aware" diff/merge[4],
* No Such Thing As Line Breaks[2],
* Sneaky proprietary entities[3],
* NAMESPACES,
* "1NF? Is that a sex thing?",
* Computability[4],
* FRICKIN CHARSETS,
* asemantic but pretends to have semantics,
* Hierarchy Fetishism
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't believe me? Run the metrics on gitlab/github/npm/pip/DaSEA[5].
So the tool ecosystem is - very often - only as big as a singular project. It's one of the reasons there's so many XML editor vendors. In S1000D, it's pretty common to have a special vendor for each project.
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.
Using XML at scale is something that should never happen, for any reason, ever. It's this horrifying perfect storm of non-technical academics steering a crew of malcontents still angry at how GML went. Ol' 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're magnified times fifty bazillion because of the inherent lack of support.
[1] Leading whitespace in attributes? HOW CHARMING. Yeah, that'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's a flashback to the pre-ATA100/JASC 1930s "shop manual" systems.
[2] No such thing as "normalized" when it comes to XML whitespace, which means no lines, no tabs, no spaces. Everything is elements. Oh, ha ha, unless there's dual-mode DTD/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?
[3] REVBARS! Oh, and FRICKIN CGMs. Good luck processing those, because they were golden tickets handed out to ISO-favored software vendors.
[4] Infinite arbitrary nesting combined with whitespace agnostic means it'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.
Man, I wish I didn't need DTDs. Unfortunately, the USAF TMCR says I do. Verbatim. TO-00-5-3.
Yeah, in retrospect Billion Laughs was a bit of a cheap shot. It is, however, hilarious. And no one ever put forward any sort of mitigation or fix, for decades[1]. Meanwhile, in the YAML dev world open issues . .
if (refDepth > maxRefCount && node.kind === Yaml.Kind.ANCHOR_REF) {
I don't really have a dog in the YAML fight - apart from Asciidoctor-pdf template files[1] - but the YML people are patching, and the XML people didn't, for a very long time.
Why is that? I'm going to go back to the basic notion of XML as the Everything for Everything, which was encouraged by its design pattern insistence on fake semantics. YML has, no doubt, a big ol' dose of the same sickness, but with a lot less overhead, and it makes maintenance easier.
Keep in mind, we're now debating "How YML is perhaps just as bad as XML"
[1] This has resulted in a lot of software and IETM files (even whole devices) getting pulled from USN vessels in theatre; there's more than a few vulnerabilities that ride on the SGML/DTD Billion Laughs. Bunch of other ancient file formats getting the same treatment, something we in the industry saw coming since 2007. Just a ticking bomb until you fight a peer.
Not a whole lot. And not just XSD, there's nothing either SGML or XML do that can't be done, fifty times faster, with fewer keystrokes, on standard - i.e., commodity, open - tooling, in Asciidoc (as it's deployed) or "Markdown" (with extensions).
USAF hasn't yet gotten nailed with the DTD attacks the way the USN was[0]. And that was a complete musterfluck. First they pulled all the handheld maintenance devices, then they basically mandated that all the stuff getting stuffed into entities could instead get shoved into a black box XML element stuffed full of Base64 or reference to an external binary or - hell - whatever you want. That's the current solution: the //multimedia element.
You'd think USAAF and USAA[1] would have learned something from this . .
[0] That's changing as we speak; DIA has a bunch of hardass new IT policies rolling out. God be praised.
[1] Although the USAA spec has more flex in it when it comes to geometry and other extremely specific rendering behaviors. It's much easier to optimize because it's not insistent that a frickin PDF parts catalog have draftsman-perfect line art.
Here's what the entities (specifically, CGM, the 800 lb gorilla of external entity references) do that can't be done in XML+SVG: ISO/IEC CGM:1999 line types (your dashed lines are exactly right); ISO/IEC CGM:1999 nurbs (so that the curves are just right). I have a bunch of counterarguments to these things and more, but the easiest one is : how much is a perfect dashed line worth? Is it worth twenty two million dollars? Because that's what it cost the Navy. That's assuming the PLAAF/PLAN doesn't hop inside your maintenance network off the east coast of Taiwan. Then you can buy your dashes at the reasonable cost of a few hundred dead sailors.
They need to swap out //multimedia for a standardized, text-based format yesterday, though. Either that or release an ISO profile for SVG, which honestly would be, like, a week's worth of work at most . . if you wanted to see it done, of course. Oh ISO Technical Steering, you and your loveable scamps made up almost entirely of stoneage software industry reps.
Because NONONONONONO . .
OK seriously. Seriously. These people all chillin' here in the future and talking about how great XML is need to jump in my DeLorean back to 2002. Or maybe try using XML for a few years. Or decades.
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't believe me? Run the metrics on gitlab/github/npm/pip/DaSEA[5].So the tool ecosystem is - very often - only as big as a singular project. It's one of the reasons there's so many XML editor vendors. In S1000D, it's pretty common to have a special vendor for each project.
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.
Using XML at scale is something that should never happen, for any reason, ever. It's this horrifying perfect storm of non-technical academics steering a crew of malcontents still angry at how GML went. Ol' 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're magnified times fifty bazillion because of the inherent lack of support.
[1] Leading whitespace in attributes? HOW CHARMING. Yeah, that'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's a flashback to the pre-ATA100/JASC 1930s "shop manual" systems.
[2] No such thing as "normalized" when it comes to XML whitespace, which means no lines, no tabs, no spaces. Everything is elements. Oh, ha ha, unless there's dual-mode DTD/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?
[3] REVBARS! Oh, and FRICKIN CGMs. Good luck processing those, because they were golden tickets handed out to ISO-favored software vendors.
[4] Infinite arbitrary nesting combined with whitespace agnostic means it'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.
[5] https://dasea-project.github.io/DASEA/