I wonder, for what are the use cases today one would prefer XML over JSON/GRPC/GraphQL etc ?
https://annevankesteren.nl/2007/10/xml5
I wrote a parser for it, but it never got traction.
I might have to rewrite it again.
http://www.textuality.com/xml/xmlSW.html
XML-SW drops the internal DTD subset entirely, including entity declarations; this means it doesn't support named entity references except for the predefined ones (apos, quot, gt, lt, amp). I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them.
I'm also not sold on the whole "HTML-style error-recovery" idea in XML5. In my mind, the syntactic strictness of XML is a virtue not a vice.
I'd support killing processing instructions as well. They are rarely used, and XML namespaces could be used as a replacement.
Having used and written a parser for a similar recoverable localization language (https://projectfluent.org/) I'm sold on it.
It makes a lot of things easier. It's kinda like adding trailing comma to lists. It's both boon when writing lists by hand and generating it via code.
> I think DTDs are one of the ugliest things in XML (and also a well-known source of security vulnerabilities), and it is great that XML-SW (unlike XML5) mostly kills them.
Hm, that's strange. I'm pretty sure XML5 killed DTD outright, other than having a doctype definition. Perhaps the spec was outdated a bit.
XML5 had a few big ideas:
- Ending DTD
- Unquoted XML attribs
<elem atr1=value>
<a><b></a></b> // Became <a><b></a> <b/>I'm just going by what is at https://annevankesteren.nl/2007/10/xml5 which gives the impression that <!ENTITY> declarations are still allowed.
I think there might be a misconception here. HTML5 does have some ad-hoc rules around script, style, and noscript elements, but the vast majority of tag inference it does is straight from SGML, from which both HTML and XML are derived. Tag inference in SGML is driven by (parent) element content models and per-element tag omission indicators. For example, a minimal HTML doc can look as simple as
<title>XYZ</title>
<p>body text
<html>
<head>
<title>XYZ</title>
</head>
<body>
<p>body text</p>
</body>
</html>
SGML is formalized in ISO 8879:1986, and there's absolutely nothing vague or speculative about the kind of tag inference it does. It's just that most people don't seem to know SGML and come up with ad-hoc XML extensions that can't be taken seriously without reference and alignment within the greater SGML context when XML itself is specified as a proper SGML subset.
It's interesting that you'd be willing to trade processing instructions for XML namespaces. Most experts, including the article's author, seem to agree that namespaces and XML Schema are the worst XML offenders, taking the just gained simplicity of XML away on the spot.
XML Schemas were the End of its simplicity.
So, whatever reason JSON won it wasnt that.
That said, xml could have worked out fine if there had been sane management of it's evolution. But now the cat's out of the bag, and we got json, and the "named-to-be-a-loser" YAML.
Maybe someday that kind of ambition will lead to something great, but we needed a step back.
XML is awesome for configurations: with proper XML Schema and proper editor (I use Jetbrains Idea, but there are other options) you'll get almost full validation, auto-complete for free.
I would prefer XML for any markup.
JSON have one important advantage over XML without DTD/Schema: it's impossible to express array in XML. Another less important advantage is that there's only one way to stringify graph of arrays/maps into JSON. With XML there's no "official" standard, there are plenty of different ways to write maps, for example. But DTD/Schema solves those shortcomings.
The advantage that a ML can have over another is how easy it is to:
- parse by the machine
- read and edit by humans
- esoteric features like cyclic dependencies
- sizeI had to edit Liquibase configs in YAML and XML. YAML was a fucking nightmare.
I still get flashbacks to maintaining XSLT sometimes. It was a tool that didnt really need to exist and arguably did more harm than good by being "recommended".
I remember very clearly that although XML had tooling for schema validation it was awful and people tended not to get beyond the "DTD vs XSD" debate before giving up on it. Both of them sucked.
Then there's XPath. Why XPath? Because if your markup language doesnt map to normal programming data structures you need a band aid to fix it.
As for SOAP.... that can die in the fiery pits of hell with XMLSpy.
DTD is mostly just an attack vector. XSD or Relax NG are both solid. XQuery was kinda useful but XML people went too far and started adding shit that it doesn't belong to it.
XSLT like has one or two credible use cases, like replacing entity expansion from DTD. Rest of it was just like XML database doomed from the start.
SOAP. I never saw it actually being used.
Most of this tooling has equivalents that are barely used because they didnt really need to exist in the first place (e.g. XSLT) or were a band aid over problems with XML itself (XPath / XMLSpy).
That leaves JSON schema, which - still more pleasant than XSD or DTD.
How do you express easily “every element that has X in its path” with a programming language? Of course you can write such a program but it is similar to regex - you could write a FSM but it is much easier to use a DSL for that.
Not a fan of XML, but I think XML Schema is one of the better Schema solutions I have used. If you doing something with XML and not take advantage of XML Schema it seems like a waste.
XML for markup is okay, but usually I just use a subset of HTML5 when doing that, XML would have the benefit of having XML Schema support for validation, but I have class that can do that for me with HTML5.
- numbers are a mess. You can have the full decimal numbers, the "e" notation, and sometimes you have to use strings for number that are too big for JavaScript.
- Map keys order is not significant, so it can be any order.
The post here for your convenience:
"What is XML good at?" (For the purposes of this post, I'm including HTML in the XML family.)
XML/HTML is good when:
1. You have two dimensions of markup you want to do. That is, you have a clear distinction between what is a new "tag" and what is an attribute on that tag. If you can't almost instantly decide whether some feature you want to add works as an attribute or a tag, you probably shouldn't be in XML.
2. Almost every tag one way or another contains some text, the third dimension that XML supports. A proliferation of tags that never contain any text is a bad sign. A handful may not be a problem, e.g. "hr" in HTML, but they should be the exception.
3. You have a really good use case for XML namespacing, the fourth dimension of information that XML supports, in which case there's almost no competition for a well-standardized format, as long as you're also using the previous three dimensions.
There's sort of this popular myth that XML is useless, which I think isn't because it's true or that XML is bad, I think it's because in general, most times you want to dump out a data structure #1 isn't true, let alone #2 or #3. In a lot of data sets, you've only got the two dimensions of "simple structure" and "text", not annotations on the structure itself. (Or, perhaps even more accurately, they end up implicit in the format itself, and the format is constant enough for that to be just fine.) A lot of stuff in the 1990s and 200xs used XML "because XML" even though it clearly failed #1. XML is really klunky when you don't want that second dimension because the XML APIs generally can't let you ignore it, or they wouldn't actually be XML APIs.
On the other hand, when you learn this distinction, you do come across the occasional JSON-based format that clearly really ought to be XML instead. You can embed anything you want into JSON, but when you're manually embedding a second structure dimension into your JSON document, it loses its advantages over XML fast. If you've ever seen any of the various attempts to fully embed HTML into JSON, without leaving any features behind, you can begin to see why XML or XML-esque standards like HTML aren't a bad idea. HTML is much easier to read for humans than HTML-in-JSON-with-no-compromises.
And if you've truly got the four-dimensional use case, XML is really quite nice. When you need all the features, suddenly the libraries, completely standardized serialization, and XPath support and such are all actually convenient and surprisingly easy to use, for what you're getting.
Some examples: HTML is a generally good idea. SVG is a middling idea; it passes #1 and #3 but fails #2. SOAP and XML-RPC is generally a bad idea; SOAP fails #1 and #2 but sort of uses #3 and XML-RPC fails all three. XMPP I actually think is pretty solid as an XML format (mere network verbosity problems can be solved with an alternate encoding, though admittedly that becomes non-standard), and in a lot of ways, the real problem with XMPP isn't so much the format itself as that people are not used to dealing with the four-dimensional data structures that result. People expecting IRC-esque flat text are not expecting such detail. Using the fourth dimension of namespaces for extensibility is neat, but few developers understand it, or want to.
How about: markup languages are good for encoding text, and everything that isn't directly part of text content ("metadata") goes into attributes? Arrives at about the same judgement regarding the relative merit for the use cases you mentioned.
I'd like to add that, while XMPP is XML-based, it might be more suitable to use a full-blown SGML parser to deal with XMPP streams being presented as incomplete XML (eg end-element tags missing) which SGML can deal with in a formal way (end-element inference).
It's not that end tags are missing in XMPP, just that the "document" is streamed so it isn't all available at once. Any common SAX-style parser can deal with streaming documents.
Also: why the fq order matters