In Defense of XML (blog.frankel.ch)

The article compares XML with JSON and YAML. That makes sense for some applications, but for other applications, like a structured text, I'd compare it with Markdown. I'm not happy with XML or Markdown for my source, where "source" means what I edit or what I put under version control, which aren't necessarily the same thing. I find it better to invent my own adhoc notation and write a Perl script to verify it and convert it into XML, HTML, Markdown, JSON, ...

It's a shame, but the sad fact is that humanity does not yet have an adequate and widely used way of representing structured text in a computer. XML is perhaps the closest I've seen, but the tools don't seem to be good enough or sufficiently available, and now XML is also unfashionable so I don't suppose the situation is going to get any better.

    document.contentType
    //"text/html"
    document.body.namespaceURI
    //"http://www.w3.org/1999/xhtml"

    script = document.createElement('script')
    script.textContent = '</script>'
    script.outerHTML
    //"<script></script></script>"

The major issue with XML is all the garbage built on top of it like SOAP, WS-* and horrors like XMLDSIG.

Used purely as a markup language it's ok but you really don't want to be mucking around with stuff like canonicalization at all if you value your time.

    /* a simple data structure */
    struct Point {
        int x;
        int y;
    };
    
    <point>
        <int name="x"></int>
        <int name="y"></int>
    </point>
    
    /* a recursive data structure */
    struct Person {
        std::string name;
        std::vector<Person> children;
    };
    
    <person>
        <string name="name"></string>
        <vector type="person">
    
            <person>
                <string name="name"></string>
                <vector type="person">
                </vector>
            </person>
    
            <person>
                <string name="name"></string>
                <vector type="person">
                </vector>
            </person>
    
        </vector>
    </person>

    <person>
        <name></name>
        <children>
            <person>
                <name></name>
                <children>
                </children>
            </person>
            <person>
                <name></name>
                <children>
                </children>
            </person>
        <children>
    </person>

    <person>
    <name></name>
        <person>
            <name></name>
        </person>
        <person>
            <name></name>
        </person>
    </person>

No need to defend XML. XML stands the test of time. Yaml has become the evil it was meant to replace.

If XML had-had a command line structured editor at the beginning and integrated with JS a little bit better, it wouldn't have ever fall from grace.

It pains me that json doesn't have comments, and that so much energy has been expended basically getting JSON to the tooling and conformance support that XML already had.

who even cares, just use things that everyone uses. XML can be used in a schemaless manner and json/yml can be used with a schema. Eventually the more compact formats are more popular because people can use them for other things such as object dump and actually read it. And a very big config file can be handwritten and code review without too much hassle. It's not about schema or association with enterprise.

I do miss SOAP though. Why are we still writing plumbing code in 2020. And no grpc isn't the answer there is still plumbing code, what's the point?

I'm a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype.

Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow.

My biggest gripes with XML are twofold:

- It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help).

- The community seems to have this obsession with solving every problem under the sun with more XML and more specifications. I believe, this is wrong. Trying to standardise across the whole range of data interchange and configuration needs is the wrong approach, IMHO. JSON wins here, because it gets out of the way. I do wish JSON had comments and that JSON schema was better (for when you really need it), but nobody ever had an expectation that keys are unique across all JSON documents in existence, something that XML somehow insists is necessary for its elements and attributes.

But what the author is right about is that YAML is an absolute nightmare, and I can't understand why it continues to be so popular. Apart from the dozens of ways of writing booleans or strings, it's also way, way too easy to forget what level of indentation you're currently at, especially if you're navigating large files like Kubernetes or CI configs.

I think more projects (at least larger ones) should adopt their own DSL for configuration. For example, I find the terraform config format much cleaner than any of the YAML stuff.

    class="foo bar"
    lang="en-US"
    style="margin:0;padding:0"

  head, title, script, style {
    display: block;
  }

I really would prefer to use XML for my next project, but self-censored myself so that if this project is ever open source and has other contributors, I'm not instantly dealing with hordes of users who want to convert it to json for data transfer objects.

Maybe it is because my baby duck syndrome came with xml web services and asp.net web forms, but it is amazing how much scaffolding and engineering work we threw away and are now reinventing. (Wsdl, schemas, etc)

The main problem with XML is that writing a safe XML parser is difficult. But writing, say, a safe JSON parser is not much easier; writing a safe ASN.1 parser is much harder. So it's not clear whether there's a better possible declarative format.

> JSON is JavaScript native, while XML is not

Yet we have XMLHttpRequest to thank for the last 20 years of the web.

XML specified with a mix of RelaxNG and Schematron is a really nice pairing. Both are interesting and a little different to the usual schema languages.

RelaxNG is like "regular expressions for trees". It has a compact syntax like this:

    start = element library {
      element book {
        attribute title { text },
        element page { text }+
      }
    }  

.. so books in this library (root element) should have a title attribute and one or more pages. There's a (pretty geeky [] :-p) description of the algorithm here [1] (: Brzozowski derivatives + Haskell!).

Schematron is another schema language that allows specifying constraints as a series of pattern rules:

    <schema xmlns="http://purl.oclc.org/dsdl/schematron">
      <pattern>
        <rule context="book">
          <assert test="let $b := .[starts-with(@title, 'A')] return $b/page/count() >= 100">
            Books whose title starts with "A" must have 100 or more pages.
          </assert>
        </rule>
      </pattern>
    </schema>

So it allows specifying constraints that would be too tedious or impossible with RelaxNG, and allows keeping the RelaxNG grammar simple.

The test on the Schematron "assert" element in the example uses "let expressions" [2], one of many additions that makes XPath and XSLT 3.0 feel a lot like any other modern functional programming language (other features: higher order functions, maps/arrays/JSON support, and more). This presentation [3] shows a few more 3.0 features.

If lisp is for lists, then XSLT definitely is for trees! I suspect as people start forgetting the baggage of SOAP and XSLT 1.0, the language is going to become more and more popular since it is so useful. BTW, there's now a JavaScript implementation that runs on node and the browser too [4].

1: https://relaxng.org/jclark/derivative.html

2: https://www.w3.org/TR/xpath-30/#id-let-expressions

3: https://www.kosek.cz/xml/2019xmlss/Kosek_XSLT4DailyCoding.pd...

4: https://www.npmjs.com/package/saxon-js

One reason to dislike XML is that it can't actually encode text.

This is deliberate, key people involved in XML standardization really hate some of the characters (particularly some "control characters") in text, they don't think those characters should exist, so, they outlawed them in XML.

I know what you're thinking, "Just escape them". Nope. I didn't say you have to escape them, I said they're outlawed, the XML definition says these characters, whether escaped or otherwise, must not appear in an XML document and some XML libraries enforce this requirement from the standard.

Now of course if you know this will happen and you want to sidestep it you can encode all your text in some other way (e.g. as Base64) and then use XML, but wait a minute, the whole point of XML is that it's a text encoding, for encoding text, so this is crazy.

In systems I've built that are mandated to emit XML and yet are expected to handle text anyway, I patiently explain the problem and unless people seem stirred awake and back off on requiring XML, I then convert all prohibited characters to U+FFFD - the Unicode replacement character - and they can keep both halves of the resulting broken garbage.

In the early 2000s XML was like violence - if you didn’t get what you wanted out of it you just used more.... or some horrible analogy like that.

Reason XML went out of favor I think has to do with decision to focus more on efficient parsing by machine and less on readability and simplicity. There was a competition between XSD (XML Schema Definition) [0] and RelxNG [1] for defining the structure of XML. Personally I preferred RelaxNG, but at that time Microsoft and many big players converged on XSD. So XSD won but XML is out of fashion.

I wrote a XML encoder and decoder with XSD for an EDI application handling 2-3GB files in C++ using MSXML and it was very slow, improved the speed using stream parser, but still slow. Later on using libxml rewrote the parser in C with RelaxNG and the processing time reduced from hours to seconds on the same hardware. At that time as RelaxNG lost in spite of having elegant structure compared to XSD. I had a lot of arguments with my friend that RelaxNG will win because it's readable, simple and support every use case supported by XSD. But due to support from many vendors especially Microsoft (as most enterprises were using microsoft) an inferior solution like XSD won, because Microsoft focused more on computer consumption of format instead of human. So although XSD can be read no one could understand it. This is one of the reason JSON, YAML and TOML have picked up because they offer the readability and parsing at the same time. Hopefully people can understand it this time and do not destroy JSON with complex JSON Schema definitions.

Take a look at both:

   Relax NG example in compact syntax:
     element book {
       element page { text }+
      }

   Relax NG exmaple in non compact syntax:
     <element name="book" xmlns="http://relaxng.org/ns/structure/1.0">
       <oneOrMore>
         <element name="page">
          <text/>
         </element>
       </oneOrMore>
     </element>

    -------------
    XSD example:
    
     <xs:element name="book">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:string">
             <xs:attribute name="page" type="xs:string" maxOccurs="unbounded"/>
           </xs:extension>
         </xs:simpleContent>
        </xs:complexType>
       </xs:element>
   

[0] https://www.w3.org/TR/2008/REC-xml-20081126/

[1] https://relaxng.org/

    <!element book - - page+>

My biggest problem with XML was using APIs written in Java where it seemed like all the internal classes were just dumped however they came out.

I think the simplicity of JSON forced people to think about how to serialize their data. This Simple serialization made things easy for multiple languages, and therefore it became popular.

I don't disagree with every point the author makes — and I cry inside a bit every time I see YAML used for serious work, with data loss and outages caused by that ambiguous — but I think it'd be useful to focus on why XML became unpopular. Java and SOAP culture had a role there but most of it came down to two things:

1. The user experience sucked

2. The developer experience sucked

What XML needed was good quality editors, validators, programing language libraries, and, above all, documentation for people who aren't on the standards committees. What we got instead were people on standards committees and enterprise architecture groups trying to show off what deep thinkers they were, with the assumed inevitability meaning that boring details like actually implementing something could be left as an exercise for the student.

Namespaces are a great example: this is a core language feature, a really powerful tool, and you'll hit the laziest possible implementations as soon as you try to use them. You start with something reasonable:

    <foo xmlns="http://example.org" xmlns:custom="http://example.org/somethingelse">
        <bar>
            <custom:baaz>…</custom:baaz>
        </bar>
    </foo>

That's a nice way of separating ownership, looks great. Then you start trying to parse it, write XSLT or XPath, etc. and find that you can almost never write “custom:baaz" the way it shows up in the document, or often even /foo/bar, because the tools expect you to work with the internal representation (“{http://example.org}foo/{http://example.org}bar/{http://examp...) and so you might see error messages saying "<custom:baaz> not found” in a document which has that exact string, validation errors from tools which use different libraries than what was used to author the document, or, better, silent data loss because you didn't notice that some selectors weren't matching. Many programming language interfaces will require you to repeat those declarations everywhere because, of course, it would have been far too much to expect that a query against element <bar> inherit the namespace declaration from its parent.

Again, this is a key feature which has been around since 1999 and decades later you can still still find people writing things like //*[name()='baaz'] or stripping namespaces entirely before rage-quitting XML. Everything harder is worse: basic usage requires internalizing 6 different ponderous specs on different release cycles, figuring out which of the examples had never been tested and which worked when the author wrote them but are now unsupported by the particular tools you're dealing with, etc. Bonus points for realizing that you had a never-valid document which was just punted down the line by multiple enterprise systems which have had increasingly lenient validation added over the years by developers who were told it was too expensive to fix the previous system.

I'm not sure XML can be saved at this point but I'd start by modernizing libxml2 since half the open source world is stuck in stasis when that stopped getting new features in the early 2000s, and then focusing on non-expert usage. A full GUI editor would be a lot of work but simply having high-quality command-line tools and implementations for common programming languages would go a long way towards not giving people excuses to switch.

My reasoned objection to XML, having used it for many years, is that it is unconscionably expensive to parse. At scale, XML is extremely computationally expensive in almost every dimension. It is not a good way to represent almost any non-trivial data structure, but that is frequently its sole use case. XML is a great way to expand your carbon footprint in the data center.

Today, there are very, very few cases where I would recommend XML despite it being widely specified for standards.

Just as an anecdote, I recently had to generate some XLSX which, even for XML standards, is a horrible standard and the only library that seems to be able to accomplish this (for Java) consists basically of some autogenerated classes from the XML schema itself that have zero documentation.

But the worst part was when I tried to add an integration test for it. I tried comparing the generated file with a fixture file, but that didn't work, because XLSX are zipped XML files and zip isn't deterministic. But even comparing the two file directories of the unzipped files and then comparing XML files pairwise didn't really work, because apparently, XML can be serialized in different ways and it turned out that my CI somehow serialized it differently than my machine (somehow the namespaces were handled differently - not sure if it was an OS issue or some transitive dependency issue). In the end I was only able to solve it by using another library that can specifically diff XML files.

One thing not mentioned in the article is the lossy nature of XML when coming from data structures with concepts of arrays and maps. A typical array in XML looks something like:

<foo>

  <bar>First element</bar>

  <bar>Second element</bar>

</foo>

which can lead to issues if the second element isn't in there: should bar just be a property of foo or should it be an array? (I'm definitely open to correction on this if someone knows a better way; my experience with this particular issue is from writing a parser to take XML and turn it into a MUMPS-native data structure. I mostly had to have the parser take an educated guess and then let API users specify which elements were arrays if they wanted it to parse the same way against all inputs).

This is analogous to how saving Clojure sets (e.g. #{:a :b :c}) to a JSON document in CouchDB is also a lossy operation because JSON doesn't have sets, just maps and arrays.

> IMHO, this argument is shallow, as all 3 formats are text-based. Thus, you can - and should - compress files. Parsing might be a bit slower, but it depends a lot on the exact parser (and the associated technology stack). In the end, the overhead of transmitting and parsing in XML - if any - is negligible compared to the total time in the whole use-case.

That doesn't help a human reader. The XML overhead doesn't matter to computers, agreed, but it matters a lot to people.

> Composable > While XML doesn’t strictly enforces namespaces, it’s considered a good practice. This way, similarly-named entities defined in different namespaces can co-exist in the same document without confusion about semantics.

Sounds useful but it actually isn't. JSON is composable just fine: just put a JSON document as a value in another JSON document (something you can't actually do in XML, you have to strip the headers). By contrast, XML namespaces are this hugely complicated non-solution to a problem that no-one ever actually has: if you write an XPath expression then it might select something inside an embedded XML document instead of the thing you were actually looking for, because the embedded document might use the same tag name. So to protect you from this bug that has never happened, you can't actually write an XPath using the tag names you see in the document, you have to either expand out all the namespaces to their URLs (and good luck with what your XPaths look like now), or somehow "register" all your namespaces with your parser before you parse. It's just stupid overengineered nonsense.

> Several XML grammar implementations are available: Document Type Definition, XML Schema, Relax NG, etc. The most widespread one is XML Schema. Since a XML Schema is also written in XML format, a web server can host it. Then you can reference it by a publicly-accessible URL.

> This approach solves the above issues: when a client receives an XML document, the former looks at the XML Schema URL. It can then fetch it, and check that the data conforms to the schema.

> Changing the data format is as simple as versioning the XML Schema file, and publishing it under a new URL.

And then when your webserver goes down, everyone's programs stop working because they can't load your schema.

Has XML schema ever actually done anything useful for anyone?

      <pre>
    foo
      </pre>

There are a couple of things this article gets seriously wrong.

* Front-end. XML is perhaps more compatible to that front end than JSON because an XML document can make use of CSS and JavaScript where JSON cannot. See this example of a language I created in another life and please that document is literally the XSD schema file: http://mailmarkup.org/mail-documentation.xsd

Also, if you want to use either format in the front end you have exactly the same one step: parsing whether it’s using JSON.parse or DOMParser(). Actually, the browser preferences XML here too because the browser can be told to parse the XMLHttpResponse response and thereby return DOM document object. https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

* Failed for two reasons and enterprise is not one of them. XML has some super intelligent features and technologies. The more intelligently you use it the more powerful it becomes. Most people were not using it intelligently. Most people were using it in the most primitive way possible without any advanced features. In that case it was just a bulky text wrapper. Most of the Java configurations were dumb like that.

XML is big. The charm of JSON is that the syntax is tiny. When pushing data over the internet tiny is better. The only way to make up for the syntax bloat was to do more intelligent and powerful things which XML wanted to do but most users refused to figure out.

Interesting that nobody pointed out the tooling dimension of XML's demise yet. (edit: actually there was another comment too: https://news.ycombinator.com/item?id=24623696)

You really need a high level of support in editors and other tools to make it good for humans to work with, to just showing the AST and to hide the unusably verbose surface syntax. This support didn't materialize widely enough for whatever reason.

Of course you can say that it's just a convoluted way of saying the syntax wasn't good enough - but at the time the argument was that tooling will be good enougg and will solve the issue. So it's still a good lesson about tooling.

> YAML is to config syntaxes what Python is to programming languages. Seriously, significant whitespaces?

That's his critique of YAML? That it is too pythonic? You're not getting far in convincing people of something being bad, if your top argument is "It is like python".

  v% (extend selection to matching delimiter)
  /\%Vvmtype: (to search for "vmtype:" within the selection).

It's too easy to produce some abhorrent XML if you don't put much thought into it, straight from tables and objects. And then people are surprised that what they see is revolting, hard to work with and reason about.

> IMHO, this argument is shallow, as all 3 formats are text-based. Thus, you can - and should - compress files.

Not only that, but converting data to text, compressing, decompressing and back from text to data is kinda dumb; there's technologies like EXI (https://www.w3.org/standards/xml/exi) that transport XML data in a compact binary format. It may not be readable in transit, but switching the transport or converting the EXI into text-based XML should be trivial if you want to inspect it manually.

But people seem to be reluctant to have mechanical sympathy, even if the data is barely ever read by humans.

I agree with most comments ! Who can defend XML today? The best nightmare for programmer! Costing billions to ITthe industry (as all major companies use it internnaly and externally).

Probably another growth hacking news .... ;(

I don't care about anything regarding XML, except the fact that it can read files and make http requests...