4 ms·

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 st

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.

tannhaeuser 3y ago
> 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.
- Mikhail_Edoshin 3y ago
  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.
  - tannhaeuser 3y ago
    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.
    - Mikhail_Edoshin 3y ago
      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: Table { name Schema { ... } Row { enum 123 "text" etc } ... } Table { ... } 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.)
madsbuch 3y ago
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>
- qayxc 3y ago
  > It gives too many levers. 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.
- wizofaus 3y ago
  > 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).
espe 3y ago
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.
qayxc 3y ago
> 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 :)
rekado 3y ago
> 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. This is also why the Scheme syntax for XML, SXML, feels right at home in the land of S-expressions: https://en.wikipedia.org/wiki/SXML https://en.wikipedia.org/wiki/SXML
sacado2 3y ago
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.

tannhaeuser 3y ago

> 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.

Mikhail_Edoshin 3y ago
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.
- tannhaeuser 3y ago
  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.
  - Mikhail_Edoshin 3y ago
    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: Table { name Schema { ... } Row { enum 123 "text" etc } ... } Table { ... } 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.)

madsbuch 3y ago

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>

qayxc 3y ago
> It gives too many levers. 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.
wizofaus 3y ago
> 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).

espe 3y ago

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.

qayxc 3y ago

> 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 :)

rekado 3y ago

> 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. This is also why the Scheme syntax for XML, SXML, feels right at home in the land of S-expressions: https://en.wikipedia.org/wiki/SXML https://en.wikipedia.org/wiki/SXML

sacado2 3y ago

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.