XML Appliance

I think you’ve hit the nail on the head.

It was the new hot universal structured way to transfer data over this newfangled internet and interop between applications and even operating systems. It even uses Unicode(!) which was a very big deal at the time.

Prior to XML the way a lot of data got transferred was via comma-separated-value files. They have a number of limitations (to put it mildly), like how to store strings (single quotes? double quotes? no quotes at all?), what character to use to separate values (it wasn't always a comma - sometimes semicolons and pipes were used), and how to escape the in-band control characters (commas, quotes if used, newlines). If you had to share a file with another party there was a negotiation that happened ahead of time on how all that was to be done.

Example: You have to send the name of customer Finley O'Conner. Do you send it as:

  ,Finley O'Conner,
  ,"Finley O'Conner",
  ,'Finley O''Conner',
  ,'Finley O\'Conner',

And so on. But with XML the process of escaping control characters was well defined, and the receiver would commonly publish a schema definition that detailed what all the values were like (types, sizes, etc.) You could be up and running fairly quickly and with some confidence that the integration would work.

There's always some sort of hype thing going on. If you made a chart of all the industry hype going back at least the 1990s there's always something. If I were older I could probably push that date back further, I'm just sticking with what I know.

I think there were a lot of factors. One is that while it's not really true there were no interchange formats, they were all either bad, locked away behind huge paywalls, or unknown to the common programmer. It is hard to conceptualize how the industry worked before the Internet meant ten seconds could lead you to anything you like.

Another is that XML was the evolution of some pre-existing standards and the people who were behind those standards, which includes some companies who made lots of money on those standards, were very excited about an evolution and saw an influence and profit opportunity in hyping it up.

Money in general feeds a lot of the hype cycles. Even before we account for people deliberately pumping them, something that becomes slightly popular attracts money, which attracts marketing, which attracts further popularity. You can see that right now in the AI craze. (Note that being a hype cycle doesn't have to mean it's all hot air, there can be something useful in the middle of it.) Then we account for people pumping it and marketing it on purpose and the hype cycles only get bigger.

XML also got a sort of halo effect from the sudden popularity of HTML and the web. It claimed to be the natural next evolution of the web technologies, even though that never really manifested. (It didn't completely fail, either, like with SVG being XML, but it didn't take the world over either.)

It's a lot of things. It's even that it is a good solution to certain problems that didn't have a good interoperable solution at the time; even today a significant portion of XML's bad reputation isn't that it was actually a bad technology but that it was applied to tasks it very much shouldn't have been. (See "What XML is good at": https://news.ycombinator.com/item?id=11446984 )

But if I had to pick the one thing that HN might be underestimating, it was the amount of money being poured into marketing in order to drive hype cycles so that you had to pick up consulting services from Sun or IBM in order to stay current. These marketing teams bought editorials, magazine covers, would create entire conferences from whole cloth for these things, and a lot of companies would dutifully send their employees off to them in order to stay "current".

There's a lot of money to be made in these hype cycles in consulting companies and companies selling shovels. A more recent one is the whole "data lake" thing; if you've not been part of it you may not realize how much money there is in selling to organizations the idea that if you just shove lots and lots of data into a pile and let Data Experts poke through it they will inevitably discover amazing facts about your company that you had no idea about, like, "if customers have been using your product a lot they're likely to continue to" and "if customers are toning down their usage of your product, they're probably about to leave". (I sarcasm here a bit, but it's just a myth that lots of data inevitably has amazing and subtle things to learn about it.) It isn't that hard for the companies making this money to pour just a bit of that money they're making into generalized fanning of the hype cycle du jour... and rolling back around to the topic, XML got a lot of it.

The most amusing thing about these hype cycles is that they generally precede people understanding the tech and generally the maturity of the tech. Java is #1 today because Sun poured immense amounts of money into a hype cycle... yet in my highly opinionated opinion, Java wasn't actually good for much of anything until after the main cycle. XML was the same thing... people generally thought of it then just as many do now, as just some angle brackets and some vague rules, but it's actually a particular thing with particular uses (https://news.ycombinator.com/item?id=11446984) and particular tendencies, which, looking back, were not well understood by much of anybody until after the hype cycle died down. The XML-based technologies that date from the height of the hype cycle are not just verbose and unwieldy, they're also poor users of XML! One of the clearest examples is Atom versus RSS; while I'm actually generally on team RSS Is Good Enough, Atom comes from an era where people generally understood XML and it correctly specifies things and uses the features correctly, whereas RSS generally dates from the "XML is angle brackets and some attributes" era of XML, and as they solve essentially the same problem provide a really clear contrast.

> Before XML you had random binary or text formats, so APIs were a lot of work?

Before XML there was, and still is, SGML. From W3C's XML spec:

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

So XML was intended to simplify HTML/SGML syntax, and in the form of SVG, MathML, and XHTML (XForms etc.) to add new vocabularies and vocabulary evolution facilities to the web.

There was this idea that your backend service produces XML payloads, and you transform that to HTML via XML transformation languages such as XSLT. Well, it's fair to say web frontend development took a different direction ;) but the initial idea was inspired by the web being a text/markup based environment rather than becoming a desktop replacement, which it eventually did for economic rather than technical reasons ie. nobody buying software hence only "service" lock-in was left to make a living from development (F/OSS played a role in this, too).

From there, XML was then suddenly used for config files and everything else; not so much because it was a good fit, but because it sold well and was ending tool discussions in projects.

There are numerous uses where XML wouldn't be today's choice for data exchange, but where XML is extremely useful and prevailing, even unlikely ones such as for exchanging 3D CAE models with Blender, but mostly enterprise and gov document and data exchange, because in 2000s and early 2010s the expectation towards "open" systems was higher, or just simply because the segment saw enormous growth during that time.

It's not like ASN1 didn't exist (or still exist). It's hard to say what'll catch on, I guess.

Why? It's a perfectly good functional programming language... https://gist.github.com/pjlsergeant/50a3d086d9513612cb397a13...

It's name is/was Software AG.[^1][^2] What an impressively generic name. Looks like they still have an office in Bracknell.

[1]: https://www.infoworld.com/article/2661499/software-ag--the-x...

[2]: https://en.wikipedia.org/wiki/Software_AG

> I conjectured that it's Kubernetes. Just like XML, Kubernetes solves a problem, but it doesn't solve EVERY problem.

Like XML, Kubernetes does a lot of cool things which were not common before it came around (unlike XML, I think K8s actually manages to improve on the state of the art a bit, too). But just as XML was largely replaced by JSON, I am really excited to see what replaces Kubernetes.

Could you share some examples? Genuinely interested as I really only know those god awful and huge Maven configs as things one would mostly edit by hand

I love it also.

The XML ecosystem is truly staggering. I can't say if any of it is "because" of XML, or simply XML was the thing these different projects hitched their wagons too, just because of ubiquity and momentum.

It is imperfect, but still extraordinary.

One of my favorites is XSL/XLT. Yes it's a programming language in XML that's apt at working with XML. But that's the thing, you have an XML programming language that can easily manipulate XML. What other language does that remind folks of? It's also functional. Hard to hear yourself think around XSL because of all the buzzwords flying around.

An early idea, which never caught on, but was still clever, was download XSL files to the client, and then simply serving up XML files to be rendered by the local XSL. We actually did this with CDAs in healthcare (CDAs are essentially XML health care records). That was a driving thing with CDAs. There were actually contests for student groups to come up with stylings of CDAs.

The idea of stylesheets and XML is really powerful. HTML and CSS are joined at the hip, but that's happenstance. CSS can be applied to raw XML, but that aspect of it never matured like HTML and CSS did.

Then you have things like XSL-FO, giving a straight pipeline from raw XML to a formatted output.

I love XML namespaces. The idea of "hiding" meta data into XML files is quite cool. It was straight forward to consider XML elements in other name spaces as no more interesting than comments. This was used to great effect in SOAP and web services. A nice use case was bundling XML-Sig payloads. This was used in SOAP, in SAML. That was the beauty of it. In theory, you could plonk it most anywhere.

Yes, it had its problems regarding normalization and such. And, yes, XML is complicated. There were certainly some sharp corners in dark rooms to bang you head on with XML. It suffered interoperability issues, but then everything did. Everything still does. That's not XMLs fault, that's just humanity.

It's a powerful lingua franca. Once you get something into an XML format, there's so much that can be done with it, stuff we've been doing for 20 years. JSON et al are still trying to catch up, and suffering similar problems that XML has suffered through.

A simpler version of xml would have ruled the world. Name spaces and xpath killed it.

> I Love XML. Well-designed XML is better than well-designed JSON IMHO for human readability.

But both are absolutely inferior to S-expressions. Compare this (from https://www.xml.com/pub/a/2004/07/21/design.html):

    <books xmlns='http://www.example.com/books'>
    
      <book publisher="Addison Wesley">
    
        <title>Mythical Man Month</title>
    
        <author>Frederick Brooks</author>
    
        <publication-date>1995-06-30</publication-date>
    
      </book>
    
      <book publisher="Apress">
    
        <title>Programmer’s Introduction to C#</title>
    
        <author>Eric Gunnerson</author>
    
     <publication-date>2001-06-30</publication-date>
    
      </book>   
    
    </books>

to this:

    (books (ns "http://www.example.com/books")
           (book (publisher "Addison Wesley")
                 (title "Mythical Man Month")
                 (publication-date "1995-06-30"))
           (book (publisher "Apress")
                 (title "Programmer’s Introduction to C#")
                 (author "Eric Gunnerson")
                 (publication-date "2001-06-30")))

The S-expression is trivially parseable; the XML, OTOH, requires a fairly complex (hence potentially buggy and insecure) piece of software — and if you’re not careful, you’re susceptible to a billion-laughs attack. The XML will be littered with extraneous text elements between the tags; the S-expression is not. The S-expression just has atoms and lists; the XML has both tags and attributes. Why is publisher an attribute while title is a tag? Who knows?

It’s probably not a coincidence that a Google search for "well-designed XML" yields very few results, with your comment one of those few.

Were they doing a lot of CORBA before that? If so, I might have run towards XML/SOAP too.

> Most important reason XML was replaced by JSON for the majority of use cases was the parser had a lot of complexity and wasn't implemented as well for other languages...

I think it had more to do with:

1) An advantage of XML was supposed to be that it was human-readable, which meant it would be easier for developers to work with and debug. The problem was that many XML documents were so bloated with tags within tags within tags and redundant attributes all over the place, that in practice it was extremely painful for a human to read. JSON is better, in practice.

2) For better or for worse, JavaScript became ubiquitous, and there is a simple, clean isomorphism between JSON to in-memory JavaScript objects (obviously, since that's what the JSON name means).

Hell is others’ XML.

I will take XML over YAML any day.

It's not. It's much more simple, than anything else I know. XPath, and its higher-up XQuery make it a breeze! XSD, while not perfect, can be easily displayed as a graphical diagram. What you, however, need, and there is no way around it, is a specialized XML IDE or an IDE, that has "understood" XML.

I was asking specifically about if this "XML hardware" was still in use