XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because you can get a rather concise and elegant result. XML is normally way more verbose, although not that much, if well done. Yet the expressiveness is exactly the same.
Notation is what you need when you manually compose some data for machine processing. XML as a data interchange format is a misuse. Yet XML as a data description format is what it is very good at. The difference is that data interchange goes from one machine to another, but data description is what goes from a human to a machine. Data input, in other words. Complex data input. Language-like data input.
This is why XML is widely used, for example, in user interface frameworks where you need to describe very elaborate data structures. Markup is another obvious example; here you also have complex data structures tied to a piece of text. Yet markup is just a special case.
So if we are to add something to this article’s sentiment it could be an observation that we are also prone to misunderstanding things and jumping too quickly to conclusions.
> XML is somewhat unique as a concept. There was nothing like it and still isn’t.
That's just incorrect. XML is a proper SGML subset, nothing more. Why do intelligent people like you come here to lecture about markup languages but don't even bother to read the XML specification which clearly states (as in chapter 1, sentence 1):
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.
Indeed it is. But being simplified and separated from SGML it somehow revealed a clearer idea of what a notation is. SGML is a markup language and as far as I remember it (not too well), it never was disassociated from the text; maybe it was possible, but not widespread. XML without text content is perfectly usable and is even more convenient.
What you're saying is that you were first introduced to these concepts when XML came up. Totally understandable given the hype, but I can only suggest to look deeper, where things become interesting. For example, have you ever wondered about the reason for XML's obvious, excessive redundancy requiring matching end-element tags to be specified in full, when "</>" (as is possible with SGML) is sufficient given that XML doesn't have overlapping markup (as in SGML CONCUR)?
As to use of markup for non-text, I have to disagree. Markup is precisely for rich text. For representing discrete data there are much simpler and more compact alternatives not involving attributes-vs-elements decisions and hierarchical addressing of nodes which don't make sense where there isn't a concept of "rendering" a document to a user.
I precisely advocate using non-text XML as well. It is not to represent data per se, but to represent it in a human-friendly way. To represent data for a computer the best way would be to serialize in some reasonable manner a subset of a database:
That is all. Truly, a very good form, suitable for anything, not biased in any way. But it would not be easy for a human to author such a subset without quickly getting lost in tables and records. Yet somehow humans can write gigantic volumes of code. So it is not that it is difficult for us to type or something. What makes writing code easy compared to describing a set of tables?
Writing code follows some structure, the grammar. And grammar ends up in an AST, which thus exists there all the time and is the only thing that gets to the computer; text is only the medium. Let’s render AST as XML and see what remains if we drop all text. I see the following: 1) element type and attributes, 2) names and references, 3) an element encloses other elements, 4) elements come one after another. The first two are present in the database form as well, but the last two do not. I think composition and ordering are precisely the tools that let us to implicitly embed some information and make it possible to author large amounts of structured data.
(Textless XML by definition has no elements-vs-attributes problem. All goes into attributes except things that have to go into elements. Usually it is not hard to decide: they can repeat, or depend on order, or appear elsewhere; very similar to database normalization.)
You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does.
The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections.
This is IMHO the weak point for XML: It gives too many levers. when we don't know how to assign meaning the the levers, we arrive at garbage like the example from another comment: <ssn ssn=“123”/><id>123</id>
"My guess it that this is to model OOP-based systems:"
No, SGML which became XML is a separate independent track from OOP. They both set themselves up in some concrete before they really encountered each other and the contact was a mess. This is part of why the DOM, especially the first couple of iterations, are so messy (reading DOM 1 is almost hilarious in hindsight, if you know what you're reading for [1])... it doesn't help that the DOM also smashed into yet another tech line, the dynamically-typed scripting language, face first. The hasty three-way committee-arranged shotgun marriage in the late 1990s between these techs produced a fairly dysfunctional family.
[1]: https://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html Notice this API, primarily used by Javascript, is specified in Java, complete with specifications of checked exceptions. Total clusterfuck. And a prime example of just how hard Java was inorganically jammed down the programming community's throats (which I say without regard to your current opinion of the language, it did grow up certainly, but the initial push was completely inorganic); this standard is 1998, with Java 1.0 release 1996. Java 1.2 (or 2.0 depending on how you look at it) was released in 1998, with such notable features as... the first Collections support in the library. This was not a language mature enough to be writing specifications in yet, even ignoring that you shouldn't be writing specifications like this in a specific language anyhow, especially since it was obvious and known it was going to be cross-language anyhow.
I don't agree that the horrible XML example is the result of that.
There's a simple semantic difference between attributes and elements in XML:
* there's only one instance per attribute
* attributes are atomic (i.e. have no children)
* attributes are order-independent
So whenever your data is atomic, the order in which it appears doesn't matter, and you only want one instance, (per element) you'd use an attribute. The reasoning behind this is to enforce basic semantic rules without having to resort to complex schemas like XSD or RELAX NG.
It has nothing to do with OOP: it's just a very basic tool for enforcing basic constraints. As with every tool, it can be misused or ignored. The XML example is the result of incompetence and/or lack of coherence in data modelling and processing (judging from the micro services mentioned), not a weakness of XML as such, IMO.
> My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections.
Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental difference if they were never part of the spec and you had to use sub-elements to define such properties, except perhaps for the fact an attribute of a given name can only be declared be once (which an interesting difference between JSON and XML - XML lacks any syntax for declaring arrays, so you must be able to declare multiple sub-elements with the same name).
as can be seen to the comments to to my comment, there are quite a number of ideas on the ontology of the XML format. when a single screen worth of text on my phone can hold at least 3 strong convictions on how to use a format, then it is doomed to fail.
Just as an anecdote: about two years ago I had a discussion about marshalling data structures into XML and indeed, two people managed to come up with three different schemes [0]. Of course that spells doom for something that's supposed to be used as a data-exchange format.
Children and attributes are different. Attributes are like fields to a record. Parent/child is a relation between records.
There are clear criteria for choosing attribute vs text representation. Text is for humans; all the rest is for the computer. If we see something like this:
<ssn>123</ssn>
this means the text is precious and we cannot alter it, only attach some records (‘ssn’) to some character ranges. And in most cases these records need more fields, so we add attrbiutes:
... <date date="2001-01-01">the first day of that year</date> ...
This is the usual case in markup: we need the computer to do something with the text and use the records as a guide.
But a notational case is different. With notational case we still need the computer to do something, but not about a particular piece of text. (This is actually the general case while text-handling is a specific one.) In this case we can command it directly:
<foo>
<bar id="a" />
<baz ref="a" />
</foo>
There is no text in these records, but we still use notational tools: 1) node type, 2) composition, 3) ordering, 4) naming/referencing. In this case we put everything into attributes.
We can have a notational piece with markup parts or a markup part with notational parts, but each has a clear purpose. There is also a third specific case: we want to switch to another notation and in this case we write it as text inside an XML element.
SVG is a good example. All data go into attributes, text inside elements appears only when 1) it is a part of the drawing, or 2) we are switching to another notation:
<!-- notational -->
<svg ...>
<!-- switching to CSS, still notational -->
<style>
...
</style>
<!-- markup -->
<text>... <tspan class="...">...</tspan> ...</text>
<!-- notational again -->
<rect ... />
</svg>
If you need the things that XML has, no, JSON is not simpler. It is more complex. Every attempt to embed XML/HTML into JSON has resulted in something worse than XML/HTML... and they are all different, too, which is bad.
The main problem with XML is that most people don't need what it has. The main problem with XML in the late 1990s and early 2000s is that it was jammed in many places that did not need what it had, and put a bad taste in developer's mouth as a result. It's actually a good solution for its niche, and that niche is large enough it isn't going anywhere, but it is also still only a niche. In that niche you're crazy to try to jam JSON in; out of that niche you're crazy to use XML. The mythos that XML is useless persists because the latter category is a much larger one.
> So if we are to add something to this article’s sentiment it could be an observation that we are also prone to misunderstanding things and jumping too quickly to conclusions.
I'd add another observation: most of the cynical views expressed in the article are simply the result of "hammer syndrome": hand a person a hammer and everything starts looking like a nail. Overuse of tools and trying to apply them to problems they weren't intended to solve, is a big issue.
Ignoring lessons from the past is another. I love how the author makes it sound as if NodeJS and trying to use the same ecosystem for backend and frontend was something new. "Write Once, Run Everywhere!" was a slogan that predates NodeJS by over a decade :)
Yes, one of XML's killer feature is that it can model rich text documents as much as ASTs. There's a reason why HTML never ever became JSON-ML, or why LibreOffice uses XML rather than JSON to save files.
In a way, XML can be seen as a generalization of simpler formats such as markdown (for text) and JSON (for structured data). Yes, I'm oversymplifying it.
mostly agree. not only a notation tool though - you can see some familiarity to scheme, that data is also an actionable description, and literate programming, that this actionable description is also a human readable description. together with its tooling XML still has its very own space. XSLT feels quite elegant once you get the hang of it.
Notation is what you need when you manually compose some data for machine processing. XML as a data interchange format is a misuse. Yet XML as a data description format is what it is very good at. The difference is that data interchange goes from one machine to another, but data description is what goes from a human to a machine. Data input, in other words. Complex data input. Language-like data input.
This is why XML is widely used, for example, in user interface frameworks where you need to describe very elaborate data structures. Markup is another obvious example; here you also have complex data structures tied to a piece of text. Yet markup is just a special case.
So if we are to add something to this article’s sentiment it could be an observation that we are also prone to misunderstanding things and jumping too quickly to conclusions.