16 ms·

The XML spec is 25 years old today

134 points by klez 4y ago

cryptos 4y ago
XML is nowhere near "hip" these days, but I think it is underrated. Yes, a lot of bad things have been done with XML, but the technology itself is just fine and sometimes hated for the wrong reasons. XML is considered overly verbose, which is not always the fault of XML, but of how it is used. <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.9.2</version> </dependency> Could (in principle) be written as: <dependency groupId="org.junit.jupiter" artifactId="junit-jupiter-engine" version="5.9.2" /> What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema. See also: http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml.html http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml....
- Hendrikto 4y ago
  Isn‘t that element vs attribute dichotomy one of the main drawbacks of XML? You don‘t have that with other formats.
  - funcDropShadow 4y ago
    Somehow this is only mentioned as a drawback of XML, not of HTML --- usually.
    - raverbashing 4y ago
      Because in HTML it's clear what's an attribute and what's content In the case above, not so much (though I'd say it's the artifactId) But since XMLers like waddling in verbosity and bureaucracy it seems they shot their own foot with it
    - EdiX 4y ago
      Because HTML is a markup language. XML is also a markup language but people somehow insist on using it for things where a markup language is not appropriate (which is almost everything).
      - butlerm 4y ago
        XML is rarely used as a markup language, in fact it is almost a failure as a markup language, witness the non-use of XHTML. It is a markup language that turned out to have more utility as a general purpose data format, and it certainly didn't get that way by people using it for applications it was not intended to support.
  - HelloNurse 4y ago
    It's usually forgotten that XML is intended as a markup language: text is the main content, text is contained in elements, and elements might have properties (i.e. attributes). Elements with no text children are a special case of mixed content, not the norm.
    - butlerm 4y ago
      By the time the XML specification was standardized from the more general SGML, I don't think there was any idea of using it only as a markup language. The XML specification lists support for a wide variety of applications as one of the design goals. Even schema validation, which long preceded XML, is something more commonly used for data not text. By this point XML is so rarely used as a markup language (by comparison with its usage as a data format) that the "Markup Language" part of the title is almost a misnomer.
  - ivan_gammel 4y ago
    It’s ambiguous only until you define a design convention for your schema. The rule can be as simple as using attributes only for simple non-user generated values (eg order, postal code, birth date or name is an element, uuid or timestamp is an attribute). And clients just map whatever defined in schema.
- type0 4y ago
  A lot of bad rep for XML stems from the decades when it was "when all you got is a hammer, everything is a nail" XML shall be used for Good, not Evil.
  - pixl97 4y ago
    The saying I remember from back then is "XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it."
    - sk5t 4y ago
      See also: WS-Deathstar
- zaphar 4y ago
  XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. 9 times out of 10 for data transport you want SAX parsing not DOM. Unless your XML is actually a marked up document DOM is overkill. But many data transport libs used to use DOM which has a very real performance cost. I'm not sure how much of that is still true but the reputation for bloat and being heavy weight was often caused by parsing to DOM and then deserializing from there.
  - tablespoon 4y ago
    > XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. That's not the standard's fault. DOM and SAX (or rather streaming parsing in general) both have their places, it's up to the developer to know when to use which. Of course, developers often make bad choices, but the only way a standard can "solve" that is by forcing a developer to make bad choices in some contexts, so it's not the developer's fault anymore.
    - zaphar 4y ago
      It's not the standards fault per se but that doesn't change the fact that the standard now has a reputation whether it wanted it or not.
  - planede 4y ago
    I have some experience with libxml2. I would say DOM parsing is partly inefficient due to the many small allocations, and the library does not offer fine grained control over it. The allocator is globally replaceable, but that's not very flexible. I wished many times if I could just use an arena with a dumb allocator for a small document and just drop it when I finish with the document, but it's not very easy to do with libxml2, unless you write your own DOM parser on top of SAX.
    - sgerenser 4y ago
- hermitcrab 4y ago
  "Welcome to Niche Software, a MicroISV based in Wellington, New Zealand. " Ahh, "MicroISV". That is a term I don't hear enough these days!(Greetings from a UK based micro MicroISV)
- revskill 4y ago
  JSX is standard today ?
- D13Fd 4y ago
  The fact that you can use it in two ways, one of which is bad, is not really a good thing.
- gjvc 4y ago
  Yes! The Caucho Resin server https://caucho.com/ https://caucho.com/ used / uses RelaxNG as its schema, and , amazingly flexibly, allowed for either attribute- or element-based configuration, the latter being much more pleasing to the eye in many cases. I don't think I've seen such flexibility anywhere else.
  - gjvc 4y ago
    oops! I mean "the former" -- attribute-based configuration being much more pleasing to the eye
- indymike 4y ago
  > What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema. As someone who was involved in making XML based international standards (HR-XML), I think what made JSON great was that it was so simple that there was initially no industry to be made out of making schema. XML had so many ways to do things a schema was needed. JSON? Not so much.
- BoppreH 4y ago
  The problem is that XML is a markup language, which is entirely incompatible with the way data is usually structured in programs. Your example is simple enough, but consider the following: <root> This is some text. <type1 attributes="yes"> This is content with <i>markup</i>. </type1> <type1> Another element of the same type. </type1> <type2> And this is an element of an entirely different type. </type2> This is more text. </root> How the hell can I map that to my data model? My application data will, at worst, be a graph of class instances with named fields, containers (lists, sets, etc), and primitives (strings, ints, etc). The fact that XML has both attributes and subelements is already a huge impedance mismatch because classes have a single namespace. But what do I do with the repeated element? With the text interspaced with tags? What's the API to navigate this mess? I'm pretty sure that's why JSON won: it started from the application data model and just simplified it (no custom types, trees only). A deserialized JSON object doesn't even need an API, it's just a nested structure of built-in types found in any modern programming language.
  - ivan_gammel 4y ago
    This is a made-up problem that never existed in reality. On practice if you have to deal with a mix of text and elements, it is always deliberate and explicit choice which probably makes sense. In my decades long career I have never seen it, so it must be a rare case. You ask about API: XML mapping problem has been solved more than 20 years ago and standard cross-platform API exists since then. Have you ever heard of DOM? Have you ever heard of data mappers? XML Schema-based code generation? In modern Java you can even use the same mapping both for JSON and XML. There are two reasons why JSON dominates in certain applications: easier to write a small structure, browser-friendly. XML still has advantages in large datasets and schema validation.
    - AtlasBarfed 4y ago
      Disagree. JSON can be deserialzed to hashmaps / lists with a single call that has no schema or parsing instructions. The spec unambiguously deserializes a "data document" to a data structure. XML cannot do this: - possibility of text being just ... somewhere ... it wasn't intended. - tag data vs attribute data: ambiguous - a list CAN be represented in XML, but there is no array begin/end indicator like JSON that will confirm that the tags are a list, versus some other screwy thing - finally, JSON can represent a "data document" that is just an array/list, while XML cannot do this unambiguously. It has to have a root tag. As for schema validation, that was always a hack. Schema will ultimately encounter domain-impacted information, like "is this a valid ID in our database" that a schema rule can't encode. Because JSON is so readily deserialized to, at a minimum, hashmaps and lists, it can be readily validated with code. Virtually all JSON deserialization libraries also provide the ability (in typed languages) to provide a desired type to deserialize into, and the type information of the member variables, even lists/maps, is decorated such that those can be deserialized as well. In that case, the JSON deserialization-to-type provides an automatic schema validator with no schema rules to maintain alongside the class specification. If you REALLY like XML because it kind of self-documents a bit better or stuctures better or ... well I can't really think of a reason why to use XML, but anyway I recommend YAML as a modern replacement. God I wish XPath was ported to json/yaml/toml land though. That was the bees knees as my grandma used to say.
- thadt 4y ago
  It's been so long since being part of a debate cycle about whether a piece of data was an 'attribute' or an 'element' in XML. I had forgotten how much angst was eliminated when JSON came along like some kind of uncivilized philistine and just didn't have attributes.
  - ivan_gammel 4y ago
    In JSON everything that is not map or array is effectively an attribute. It is perfectly possible to use the same logic when defining XML schema.
- raydev 4y ago
  > It is so much more powerful and precise compared to Json Schema. Maybe so, but the continuing popularity of JSON, YAML, TOML, and recent competitors shows that developers (in general) prefer something that is both easily readable and editable by hand. Personal opinion of course, but I wouldn't call XML precise, I would call it the opposite because it's too flexible. The older I get, the more I think programming languages/markup languages/config languages should be opinionated and strict.
KingLancelot 4y ago
[dead]
fancyfredbot 4y ago
It's hard to imagine nowadays how much hype there was around XML. It was the buzzword of the day for a while. It felt as pervasive as "AI" or "blockchain" have been recently. There were many conferences on the subject, every acronym has an X for XML in there (c.f AJAX). All this for a markup language (ok, and a schema/query/transform language). It seems so weird now.
- donatj 4y ago
  Yes! XML was a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses XML to do it so take my money. So many businesses just screamed about XML. It was honestly kind of a bizarre furor in the early aughts.
  - oblio 4y ago
    > Yes! Cryptocurrencies were a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses cryptocurrencies to do it so take my money. So many businesses just screamed about cryptocurrencies. It was honestly kind of a bizarre furor in the early 2020s.
    - seanw444 4y ago
      > Yes! Rust was a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses Rust to do it so take my money. So many businesses just screamed about Rust. It was honestly kind of a bizarre furor in the early 2020s.
  - sk5t 4y ago
    Those times were all about XML and application servers like ATG Dynamo, Coldfusion, BEA, JBoss, and WebSphere, with very delicate installation procedures that probably also involved XML.
- epberry 4y ago
  That is crazy to think about. I wonder what this sentence will be about in another 25 years.
HdS84 4y ago
I am the only one who utterly despises namespaces in xml? Query a document with a namespace? Oh no results? Ah forgot to add the namespace... I had never a use case for namespaces, and the ones I can envision would have been better served by a property or attribute.
- acdha 4y ago
  Namespaces are great as a concept: I can take your standard document and extend it without any chance of conflicting in the future if you later a property or element of the same name. This is really important for interchange systems since you inevitably end up with cases where a standard format has almost but not all of the vocabulary you need. Unfortunately, namespaces as implemented in most XML tools are terrible and that's 100% the fault of the implementers. The problem is basically this: <foo xmlns:bar="http://example.org/foobarspec"> <bar:a href="baaz">hello world</bar> <foo> To a human reading that, you should be able to write a selector like /foo/bar:a or even /foo/a but as an XML parser sees the world bar is actually: {http://example.org/foobarspec}a That's an implementation detail but a shocking percentage of XML library developers did not implement a lookup mechanism to resolve it when given "bar:a". I would maintain that paying a single developer to make libxml2 suck less would have done more to help XML adoption than everything done by any XML-related standards group combined after Y2K.
- PurpleRamen 4y ago
  First thing I do in any XML-Parser I write: search/replace the namespaces. I know this is awful and impacts speed, but namespaces are so f*** annoying to handle with most parsers. Getting rid of them is the simplest solution for my sanity.
mLuby 4y ago
Here's how JavaScript's XSD validator works: > A (XSD) schema validator for NodeJS that uses Java to perform the actual validation. Why? Because Java can do schema validation and NodeJS cannot. https://www.npmjs.com/package/xsd-schema-validator https://www.npmjs.com/package/xsd-schema-validator <facepalm/>
- schemescape 4y ago
  That’s not “JavaScript’s”, that’s just a library someone published on NPM, right?
  - mLuby 4y ago
    Yep. JS doesn't have a standard library so npm is the best we've got. And speaking of the best we've got, the XSD validator above is the only one I'm aware of on npm—kind of shocking given how many overall libraries there are. It speaks to the unpopularity of XSDs among web devs, which is ironic since HTML is XML.
schemescape 4y ago
Maybe someone can help me find an obscure XML feature that I’m fairly certain I didn’t imagine: Is there a way to refer to another part of the XML tree from elsewhere in the document? I vaguely recall hearing about this feature, but now I can’t seem to find it, even after skimming the spec.
- oblio 4y ago
  Maybe https://stackoverflow.com/a/29371226/1320143 https://stackoverflow.com/a/29371226/1320143 ?
  - schemescape 4y ago
    That’s it. Thanks! Edit: id/idref
jillesvangurp 4y ago
XML basically came out of SGML which had its origins in GML, which dates back to the 1960s. With XML they sort of dropped all the hard/difficult bits and used it as a simpler serialization format for tree shaped stuff. That happened after people got annoyed with another vaguely SGML inspired thing called HTML which of course was a bit lacking in specification and uniformity at the time. Which is why this whole thing came out of w3.org. So XML was specified and then right along came XHTML 1.0 and later 1.1, which was just whatever HTML 4 was supposed to be (Netscape, Opera, Microsoft, etc. had some conflicting points of view on this) but in well formed XML shape. Of course XHTML became a bit of a problem when it turned out that browsers had to deal with mostly not so well formed HTML coming from servers. People were just slapping whatever header on top of their html to trick browsers into various parsing modes. Eventually, the whole notion was dropped with HTML 5 just standardizing all the not so well formed bits in a way that browsers could make sense of. The WhatWG was responsible for that one. When it became clear that was the only HTML/CSS interpretation that still mattered, it was grandfathered into the w3.org and since then people have stopped talking about xhtml as a thing to pursue. Around the same time the w3c lost the plot a little bit and went off and built a whole sandcastle of standards on top of XML that mostly did not get a whole lot of traction. Capital S Semantic Web vs. lower case semantic web became a thing. One was a new web reimagined on things like SOAP, XHTML, RDF, and whole lot of other things. The other was web 2.0 featuring things like RSS (almost but not quite well formed xml, depending on where you got it), micro formats, hashtags, and a whole lot of people doing rather hacky things with wordpress, php, and related things. Then AJAX became a thing when MS added XmlRpcRequest. Soon, people figured out that this stuff just got a whole lot easier if you send Json over that instead of XML. Much easier to parse from Javascript for example.
- goto11 4y ago
  > thing called HTML which of course was a bit lacking in specification and uniformity at the time. HTML was actually pretty well specified except for one crucial omission: How a user agent should treat invalid HTML. XML simply declared that a user agent should stop processing and report an error - something you can get away with when you don't need to worry about backwards compatibility. Unfortunately this left XHTML dead in the water.
spapas82 4y ago
Recently I had to convert a bunch of well structured XMLs to csvs (flattening). I downloaded the apache xalan-c (xslt engine) and xerces-c(xml engine) windows binaries from 2004 (!) and to my surprise they worked fine on windows 10. After that it was half an hour work to write a quick XSLT and convert the XML to CSV. I know that there are other (even easier) ways to extract data from an XML but I have to admit that writing an XSL transformer and see if working gives me joy. Probably I'm getting too old remembering the old days...
bane 4y ago
There's lots of comments here on XML as a file format, but that's not precisely correct (even the opening of the wikipedia article on it has the same conceptual flaw in the opening description). I think understanding what it actually is, and why it exists can really offer a lot of perspective. As somebody who lived through the emergence of XML (and HTML) from SGML, and remembers SGML actually in use in some settings, I think it's important. XML is a specification for how to create data interchange formats using a semantic, hierarchical, organizational scheme -- it's not a file format. You create data formats that follow XML, but every different schema is a different data format. What XML did, and the reason it was important, was that it made it much easier to design and specify data formats that had standard tooling for writing, validating, and reading, than pretty much any other earlier conceptualization. Before then, pretty much every piece of software, and even every different version of the same software, had a custom, usually binary, undocumented, and proprietary data format that it used to serialize data (usually as a file format on disk) or to transmit data across a network. Today, it's more or less assumed that when you serialize data to disk, or build up some data object to send over a network, it'll probably be in some kind of human readable format, figuring out how to encode your data into bits, or dump out serialized C structs or whatever isn't the common practice anymore. Even using binary serialization format like Cap'n_Proto or BSON is considered kind of unusual outside of some large organizations. Developers back in those days were dealing with a variety of CPU and memory architectures, endianness, word size, and other things that made cross-platform movement of data a total nightmare. And almost nobody documented their formats in any way, reverse engineering formats was a valuable skill in some contexts. There was some precedent for XML-like approaches. A very common one was CSV, which was often used to move tabular data between systems (and is useful to view as another "specification" for making data formats). But again, it lacks a standard specification, lacks validation, and has other flaws that make it frustrating to use for data interchange. When XML hit, it was kind of like the enlightenment happened. Developers suddenly had tooling and standards that let them not only pump out data formats in a self describing way, but schemas that also let them know they were writing the data correctly and let readers know how to parse it. Even better, a human can usually just open up a data format created to the XML specification in a text editor and just read-off the data fields and values. Long-term archival became easier, networking systems became easier, RPC and API development became almost trivial, and so on. SOAP was created because XML was created. Most of Java's built in data format stuff and RPC functionality assumes XML. Thousand page books written by a dozen authors showed up in stores trying to explain to developers all of the weird edge bits and use-cases. Then the ugly parts of XML started to settle in. The verbosity, the overengineered bits, the lack of clarity over fields and attributes, stylistic disagreements over how to organize data using it. Turns out most developers don't want to go through the hassle of writing out the validation schemas so that was usually left unused, and then most of the tooling actually wasn't very good -- for a long time good implementations of readers/writers/validators just didn't even exist for many languages. It also turns out just handling and parsing through XML, even with decent tooling, is kind of an arcane chore. Since the early 2000s then, there's been an explosion of approaches that all have learned the lessons of XML, the good and the bad, and seek to tackle various perceived shortcomings: size, ease of use, etc. XML is an exquisite crystal castle, built using the purest most elegant thinking, over decades. It turns out most people just want good enough to get it done. So most developers it seems just serialize to JSON or JSONL, gzip it, and send it over the wire or write it to disk. If you're lucky somebody will write down the fields and expected data values in a team wiki somewhere, and off everybody goes. Gone are validators, carefully crafted hierarchical data values, schemas with carefully considered semantics. As somebody who lived through the dregs of binary formats and the heights of XML, I think this is okay. But it's good to know that XML exists if extreme formalism is still needed, and binary formats are relegated to highly niche use-cases.
acdha 4y ago
I remember being excited about XML when it first came out, since there were so many clunky languages used for configuration and data storage. That feeling lasted for a couple of years, and the 2000s were basically a long disappointment as the parts I liked were buried under huge piles of enterprise ejecta. The main lessons I've drawn looking back: 1. Tool quality matters more than it might seem, and you can't count on other people to fix your mess for you. A couple of things which come to mind were the lack of a good formatter and validator (people spent too much time on things like formatting errors, especially if they were starting with a very lenient parser and things seemed to work for a while until they hit a standard one) and also the way things like XSLT/XPath shipped major spec updates but since nobody implemented them in libxml2 most developers couldn't use them, use them in browsers, etc. 2. Usability similarly matters far more than experts think: I'm using namespaces here because in my experience that spoiled more people on XML than any other single feature. The requirement that you pedantically specify the namespace in things like XPath or XSLT meant that people couldn't write those using the values they saw in front of them without getting errors or, worse, silent data loss. This reliably tripped up even experienced users and it could have been easily avoided by making a handful of key client libraries smarter. Everyone deep in the XML community has learned and internalized this but it came up over and over and over as something users hated. 3. Continuing that theme, documentation and especially examples matter a lot for the same kind of reasons. I remember about a decade ago getting evangelized by a semweb person and evaluating a couple of the things they mentioned. The only documentation available for any of the half-dozen referenced specs were the specs themselves (which were not written targeting implementers or mutually compatible), and there were no examples which I could find which matched the current versions of the specs, worked with the few public tools, or, in a couple of cases, were even valid XML. The common thread in all of this was hubris and especially the assumption of inevitability. A lot of people were aware of these as sources of friction but seemed to assume that someone else would make better tools, train people, write good documentation, maintain examples, etc. — especially since if you were the kind of person sitting on a W3C community, these were less of a problem for you since you had the knowledge & skills to keep these from being significant impediments.
didntreadarticl 4y ago
XML vs JSON is such a fascinating topic, a clash of different approaches, academic vs practical might be one way of describing it but I'm sure there's many others. Are there any good books or essays on it? And having been there in the 90s seeing XML and thinking "they've tried to do everything and got into a big mess" (XSLT anyone?) its so satisfying to see something simple and flawed displace it.
- college_physics 4y ago
  > Are there any good books or essays on it? That would be a really good resource. I mean, anybody who has worked remotely with web technologies has an opinion about this topic but it would be interesting to compile an objective knowledge base and interpretation of why things evolved this way.
- innocentoldguy 4y ago
  I despise XML, not because it was a bad idea, but because of all the bad ways I've seen people use it. For example, I used to work at an ed-tech company that bought bubble test questions from Pearson, who provided their data in HUGE XML documents. If I remember correctly, they would do things like splitting the sentences of the test questions up so half the question was a tag attribute and the other half was an element. So, instead of just parsing questions, we'd have to parse them and then stitch them back together to make complete sentences. They did that with the answers too, I believe. So weird. The JSON format makes it harder to abuse data like my example above and it is a lot easier to parse, so I'd reach for it before XML any day.
  - Thiez 4y ago
    Sounds like something that XSLT could have solved. When in doubt use more XML.
- magicalhippo 4y ago
  In a sense though the circle has been closed. With the latest JSON Schema spec, we were able to do a 1:1 mapping between our XSD's and JSON Schema, so now we can accept JSON as well as XMLs. For small messages though I agree JSON is smoother.
kzrdude 4y ago
I would want experiment with root structure of XML. Make it possible to have multiple root elements. One problem is that however big an XML document is, it has to be closed at the end, so it ends up as one atomic element, you can't partially parse an XML document correctly.
- bawolff 4y ago
  Its super common for xml parsers to support partial documents.
  - mdaniel 4y ago
    and, AIUI, XMPP is based entirely around that very idea so it's not even a niche concept (well, aside from XMPP being arguably a niche protocol)
- planede 4y ago
  What do you mean by "partially parse"?
  - didntreadarticl 4y ago
    If you imagine a log file that gets lines added to it now and then, its actually quite fiddly to do that with XML because of the closing outer tag
    - planede 4y ago
      Well, I see the awkwardness of emitting a log like that, but it's not any worse than emitting a single JSON array and waiting for that closing ']'. Both can be emitted and parsed in a streaming fashion though, but I wouldn't say that either XML or JSON is suitable for logs. Maybe NDJSON, but it's more like a hack around this limitation.
      - kzrdude 4y ago
        for json it's common to have multiple records per file. Then it's just one object per line, for example.
orra 4y ago
XML 1.0 was clearly a huge success. What I'm curious about is the seeming failure of XML 1.1. What happened there? Is it just like IPv6, in that there are too many non-upgradable legacy systems?
- planede 4y ago
  It's like YAML 1.2
- dfox 4y ago
  XML 1.1 did not "fail". It is from the start designed as slight relaxation of XML syntax rules for applications that can benefit from it, which essentially means applications running platforms where the usual encoding is not derived from ascii (eg. EBCDIC). It was never meant to be widely used.
  - orra 4y ago
    Of course XML 1.1 was meant to be widely used. The design goals[1] for XML 1.1 are the same as for XML 1.0, including being "straightforwardly usable", "support[ing] a wide variety of applications", and being "easy to create". The relaxation of names in XML 1.1 is good for internationalisation[2], by not limiting names to Unicode 2.0 characters. Allowing NEL characters, as used on IBM mainframes, was not the sole motivation for XML 1.1. [1] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-origin-goals https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-origin-go... [2] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-xml11 https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-xml11
college_physics 4y ago
Its a quarter of a century already... Enough of an empirical observation window to conclude that the way different entities choose to implement or adopt online information exchange is a tortured, highly inefficient process that is ultimately just a collection of historical accidents and technological aspects or merit are secondary On the face of it is strange that there is so much friction [0]. I will just enumerate a number of bizarre outcomes that I am aware of and I am sure there are others: * the xml web still goes strong both as-is and in large number of popular or niche-but-important domains (from html, svg to xbrl, sdmx, ...) * the semantic web (rdf, owl etc.) and making some sense of all the data exchange with metadata has gone nowhere * the API web (json) is reinventing the wheel for validation, annotation (schema etc) [0] xkcd jokes aside, people do have, in principle, strong incentives to adopt common languages and standards.
Devasta 4y ago
And here's to the next 25!
- curiousgal 4y ago
  I highly doubt computers will still exist in 1.551121e+25 years!
  - pantulis 4y ago
    And coffee was spilled! Well played!
  - didntreadarticl 4y ago
    [factorial joke]
    - oaiey 4y ago
      never explain a joke! :)
lp4vn 4y ago
XML was supposed to be a silver bullet of the myriad of ad-hoc formats for structuring documents that existed in the wild pre 2000(I got this information contested here, but that's what an old professor told me). In the XML "stack" you can find the XSL to ensure the validity of an XML document, the XPath to be a querying language, the XSLT to be a language for writing transformations, etc. I think one must at least respect XML stack vision of coherence and completeness. Then you have things like JSON where the whole wheel is being reinvented, in my opinion, for no clear purpose. You have for instance hundreds of libraries for creating a JSON schema and everything looks like a waste of time overall. Before anyone asks me, yes I have used JSON and YAML and I never could really understand why people keep recreating basic stuff like markup languages instead of sticking to whatever is available. And yes, verbosity because of the XML tag system always sounded a pretty silly argument to me.
- college_physics 4y ago
  > for no clear purpose performance may have been one driver, though for the "API web" which is the main use case there are better performing options than json > everything looks like a waste of time overall maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.
  - lp4vn 4y ago
    >maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate. Agreed.
- dtech 4y ago
  The reason is pretty clear, XML and its ecosystem was (is) enormously complex. When naively - but correctly - parsing introduces serious security vulnerabilities [1] you kinda have problems as a format. XML is just incredibly hard to get correct, understand, and be performant. JSON from the get-go was very easy to understand and start with so it gained the upper hand. [1] https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External...
NoboruWataya 4y ago
I actually didn't realise the spec was so young. I started using the internet around the same time as it was finalised. It's something you just assume has always been there. XML has its issues and personally I am always happy when I am dealing with an API or data source and see JSON rather than XML. However, there are a lot of cool things built on top of it. RSS is an obvious one that pretty much everyone here will appreciate. GPX is another really useful one. A lot of financial reporting is now also being standardised using XML. Even derivatives trading: https://www.fpml.org/ https://www.fpml.org/
- martinclayton 4y ago
  I had a similar feeling. I think it's because XML relatives HTML and SGML (GML anyone?) go so much further back.
  - butlerm 4y ago
    HTML was invented in 1993, which is not that much further back. GML was invented in 1969, and SGML in 1986. I guess you could say that HTML resembles GML quite a bit with the addition of angle brackets and urls. XML on the other hand is basically SGML with a number of optional features left out.
leashless 4y ago
I worked on XML-EDI "back in the day". When I came to the blockchain (Ethereum team 2014) I had high hopes that it might provide the architectural solution to the problems with XML in terms of workflow, API endpoints, and the (infamous) failure of WSDL ("web services description language"). I wrote it up in the Ethereum launch piece here: https://medium.com/humanizing-the-singularity/by-the-end-of-this-article-youre-going-to-understand-blockchains-in-general-and-ethereum-a-next-e11df6a1d7cf https://medium.com/humanizing-the-singularity/by-the-end-of-... === quote begins === Of course, there are attempts to clarify this mess — to introduce standards and code reusability to help streamline these operations and make business interoperability a fact. You can choose from EDI, XMI-EDI, JSON, SOAP, XML-RPC, JSON-RPC, WSDL and half a dozen more standards to assist your integration processes. Needless to say, the reason there are so many standards is because none of them work properly. Finally, there is the problem of scaling collaboration. Say that two of us have paid the upfront costs of collaboration and have achieved seamless technical harmony, and now a third partner joins our union. And now a fourth, and a fifth. By five partners, we have 13 connections to debug. Six, seven… by ten the number is 45. The cost of collaboration keeps going up for each new partner as they join our network, and the result is small pools of collaboration which just will not grow. Remember, this isn’t just an abstract problem — this is banking, this is finance, medicine, electrical grids, food supplies, and the government. Our computers are a mess. === quote ends === My company uses XML in a sort of "semantic web" paradigm to describe products, and links to these documents from smart contracts to provide accurate machine-readable descriptions of things which are for sale. It works reasonably well, and maybe it'll turn into something a lot more powerful as operations expand. So we do walk the talk to some degree.
mrgriscom 4y ago
Always a classic: http://harmful.cat-v.org/software/xml/s-exp_vs_XML http://harmful.cat-v.org/software/xml/s-exp_vs_XML
- goto11 4y ago
  If there is an argument beneath the hyperbole and i-am-very-smart posturing, it seem very weak. He end up advocating a binary format (like TCP/IP) instead of a text-based like XML because it will be faster to parse. And because a binary format is harder to change, people will be sure to get it right the first time. Yeah right.
- NoboruWataya 4y ago
  > They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished. Wow.
bazoom42 4y ago
XML shines at the intersection of structured documents and structured data. For pure data you can use JSON or s-expresssions but this does not work very well with more document-orinted data. There is a reason frontend frameworks use HTML templates or JSX even though js supports JSON natively.
- crabbone 4y ago
  Why do people advocate for JSON so much? It's simple, I can see that, but it also got most of its stuff wrong. If I had a liberty to choose a format in which I want to receive data, JSON would've been very much down on the list. These are just the problems that actually bit me in my professional use of JSON, not some theoretical possibilities: * No bounds on how big integers may be, subsequently, an ambiguity about what to do if the number is bigger than what would be considered a typical integer size for the platform: should it be interpreted as a float or as an integer? In my case, I had ids coming from a database that used 128-bit to represent them and the client side silently converted them to floats, but, on the way back, converted them to integers again, which resulted in rare collisions and lost data. * No defined semantics for repeated keys in hash-tables. I used a library that tried to stream JSON in SAS-like way, but the authors didn't realize that duplicate keys are a possibility. Again, this caused subtle and hard to identify data integrity issues. * Unnecessary null value. For some languages null and false are the same thing (and I prefer it that way too), but converting data back and forth between JSON and language-native data would sometimes produce inconsistent results, and, again, caused a once-in-a-year case of data integrity issue. * Mandatory Unicode string encoding. Caused problems with DICOMs from East Asia. DICOMs have some special encodings that can have characters not representable in Unicode. You can guess that I've learned it the hard way too. And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that).
  - rwmj 4y ago
    JSON sucks as a format. You forgot to mention the lack of optional commas, and the need to quote keys. However 'jq' is absolutely great, and that unfortunately is why we used it for some command line tools that had to output structured data.
tragomaskhalos 4y ago
As someone who has circled back into Java land recently after a number of years away, it is startling the extent to which the use of XML in this environment has boiled away to nearly nothing (the only XML file in our projects is the Maven POM), when these languages were once joined at the hip. The addition of annotations into Java has been a game-changer here, but also related ecosystems like OpenApi are using Json and even Yaml in preference.
- funcDropShadow 4y ago
  > but also related ecosystems like OpenApi are using Json and even Yaml in preference. And that explodes my mind. Yaml is such a steaming pile of shit compared to Json, let alone XML. Yaml is the perfect example for the dichotomy of easiness versus simplicity. At first glance, it looks so easy. No tags, no braces, no commas, you can use comments. It seams to be so much better than XML and Json. After a while you begin to realize that the easiness is only perceived at first glance. In truth it is agglomeration of corner cases that got hyped like crazy. See https://noyaml.com https://noyaml.com or the top answer here https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines?noredirect=1&lq=1 https://stackoverflow.com/questions/3790454/how-do-i-break-a... for examples why I have such a strong opinion of Yaml.
  - ElectricalUnion 4y ago
    My guess is yaml triggers exactly the same initial response as jquery; it's surface seems "small", "simple" and "intuitive", but once you need to actually do things and dig deeper on how it is implemented, you often wish you haven't used it.
    - acdha 4y ago
      I don't think that's fair to jQuery.
  - planede 4y ago
    YAML fucked up bad with 1.1 and YAML 1.2 has virtually no adoption. It could have been great.

134 points by klez 4y ago

XML is nowhere near "hip" these days, but I think it is underrated. Yes, a lot of bad things have been done with XML, but the technology itself is just fine and sometimes hated for the wrong reasons. XML is considered overly verbose, which is not always the fault of XML, but of how it is used. <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <version>5.9.2</version> </dependency> Could (in principle) be written as: <dependency groupId="org.junit.jupiter" artifactId="junit-jupiter-engine" version="5.9.2" /> What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema. See also: http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml.html http://www.nichesoftware.co.nz/2017/04/25/in-defense-of-xml....

Hendrikto 4y ago
Isn‘t that element vs attribute dichotomy one of the main drawbacks of XML? You don‘t have that with other formats.
- funcDropShadow 4y ago
  Somehow this is only mentioned as a drawback of XML, not of HTML --- usually.
  - raverbashing 4y ago
    Because in HTML it's clear what's an attribute and what's content In the case above, not so much (though I'd say it's the artifactId) But since XMLers like waddling in verbosity and bureaucracy it seems they shot their own foot with it
  - EdiX 4y ago
    Because HTML is a markup language. XML is also a markup language but people somehow insist on using it for things where a markup language is not appropriate (which is almost everything).
    - butlerm 4y ago
      XML is rarely used as a markup language, in fact it is almost a failure as a markup language, witness the non-use of XHTML. It is a markup language that turned out to have more utility as a general purpose data format, and it certainly didn't get that way by people using it for applications it was not intended to support.
- HelloNurse 4y ago
  It's usually forgotten that XML is intended as a markup language: text is the main content, text is contained in elements, and elements might have properties (i.e. attributes). Elements with no text children are a special case of mixed content, not the norm.
  - butlerm 4y ago
    By the time the XML specification was standardized from the more general SGML, I don't think there was any idea of using it only as a markup language. The XML specification lists support for a wide variety of applications as one of the design goals. Even schema validation, which long preceded XML, is something more commonly used for data not text. By this point XML is so rarely used as a markup language (by comparison with its usage as a data format) that the "Markup Language" part of the title is almost a misnomer.
- ivan_gammel 4y ago
  It’s ambiguous only until you define a design convention for your schema. The rule can be as simple as using attributes only for simple non-user generated values (eg order, postal code, birth date or name is an element, uuid or timestamp is an attribute). And clients just map whatever defined in schema.
type0 4y ago
A lot of bad rep for XML stems from the decades when it was "when all you got is a hammer, everything is a nail" XML shall be used for Good, not Evil.
- pixl97 4y ago
  The saying I remember from back then is "XML is like violence: if it doesn’t solve your problem, you aren’t using enough of it."
  - sk5t 4y ago
    See also: WS-Deathstar
zaphar 4y ago
XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. 9 times out of 10 for data transport you want SAX parsing not DOM. Unless your XML is actually a marked up document DOM is overkill. But many data transport libs used to use DOM which has a very real performance cost. I'm not sure how much of that is still true but the reputation for bloat and being heavy weight was often caused by parsing to DOM and then deserializing from there.
- tablespoon 4y ago
  > XML get's used in a lot of places it shouldn't be used. It also has two competing standards for parsing one of which is far too heavyweight for many of the use cases it has been used in. That's not the standard's fault. DOM and SAX (or rather streaming parsing in general) both have their places, it's up to the developer to know when to use which. Of course, developers often make bad choices, but the only way a standard can "solve" that is by forcing a developer to make bad choices in some contexts, so it's not the developer's fault anymore.
  - zaphar 4y ago
    It's not the standards fault per se but that doesn't change the fact that the standard now has a reputation whether it wanted it or not.
- planede 4y ago
  I have some experience with libxml2. I would say DOM parsing is partly inefficient due to the many small allocations, and the library does not offer fine grained control over it. The allocator is globally replaceable, but that's not very flexible. I wished many times if I could just use an arena with a dumb allocator for a small document and just drop it when I finish with the document, but it's not very easy to do with libxml2, unless you write your own DOM parser on top of SAX.
  - sgerenser 4y ago
hermitcrab 4y ago
"Welcome to Niche Software, a MicroISV based in Wellington, New Zealand. " Ahh, "MicroISV". That is a term I don't hear enough these days!(Greetings from a UK based micro MicroISV)
revskill 4y ago
JSX is standard today ?
D13Fd 4y ago
The fact that you can use it in two ways, one of which is bad, is not really a good thing.
gjvc 4y ago
Yes! The Caucho Resin server https://caucho.com/ https://caucho.com/ used / uses RelaxNG as its schema, and , amazingly flexibly, allowed for either attribute- or element-based configuration, the latter being much more pleasing to the eye in many cases. I don't think I've seen such flexibility anywhere else.
- gjvc 4y ago
  oops! I mean "the former" -- attribute-based configuration being much more pleasing to the eye
indymike 4y ago
> What really stands out is XML Schema. It is so much more powerful and precise compared to Json Schema. As someone who was involved in making XML based international standards (HR-XML), I think what made JSON great was that it was so simple that there was initially no industry to be made out of making schema. XML had so many ways to do things a schema was needed. JSON? Not so much.
BoppreH 4y ago
The problem is that XML is a markup language, which is entirely incompatible with the way data is usually structured in programs. Your example is simple enough, but consider the following: <root> This is some text. <type1 attributes="yes"> This is content with <i>markup</i>. </type1> <type1> Another element of the same type. </type1> <type2> And this is an element of an entirely different type. </type2> This is more text. </root> How the hell can I map that to my data model? My application data will, at worst, be a graph of class instances with named fields, containers (lists, sets, etc), and primitives (strings, ints, etc). The fact that XML has both attributes and subelements is already a huge impedance mismatch because classes have a single namespace. But what do I do with the repeated element? With the text interspaced with tags? What's the API to navigate this mess? I'm pretty sure that's why JSON won: it started from the application data model and just simplified it (no custom types, trees only). A deserialized JSON object doesn't even need an API, it's just a nested structure of built-in types found in any modern programming language.
- ivan_gammel 4y ago
  This is a made-up problem that never existed in reality. On practice if you have to deal with a mix of text and elements, it is always deliberate and explicit choice which probably makes sense. In my decades long career I have never seen it, so it must be a rare case. You ask about API: XML mapping problem has been solved more than 20 years ago and standard cross-platform API exists since then. Have you ever heard of DOM? Have you ever heard of data mappers? XML Schema-based code generation? In modern Java you can even use the same mapping both for JSON and XML. There are two reasons why JSON dominates in certain applications: easier to write a small structure, browser-friendly. XML still has advantages in large datasets and schema validation.
  - AtlasBarfed 4y ago
    Disagree. JSON can be deserialzed to hashmaps / lists with a single call that has no schema or parsing instructions. The spec unambiguously deserializes a "data document" to a data structure. XML cannot do this: - possibility of text being just ... somewhere ... it wasn't intended. - tag data vs attribute data: ambiguous - a list CAN be represented in XML, but there is no array begin/end indicator like JSON that will confirm that the tags are a list, versus some other screwy thing - finally, JSON can represent a "data document" that is just an array/list, while XML cannot do this unambiguously. It has to have a root tag. As for schema validation, that was always a hack. Schema will ultimately encounter domain-impacted information, like "is this a valid ID in our database" that a schema rule can't encode. Because JSON is so readily deserialized to, at a minimum, hashmaps and lists, it can be readily validated with code. Virtually all JSON deserialization libraries also provide the ability (in typed languages) to provide a desired type to deserialize into, and the type information of the member variables, even lists/maps, is decorated such that those can be deserialized as well. In that case, the JSON deserialization-to-type provides an automatic schema validator with no schema rules to maintain alongside the class specification. If you REALLY like XML because it kind of self-documents a bit better or stuctures better or ... well I can't really think of a reason why to use XML, but anyway I recommend YAML as a modern replacement. God I wish XPath was ported to json/yaml/toml land though. That was the bees knees as my grandma used to say.
thadt 4y ago
It's been so long since being part of a debate cycle about whether a piece of data was an 'attribute' or an 'element' in XML. I had forgotten how much angst was eliminated when JSON came along like some kind of uncivilized philistine and just didn't have attributes.
- ivan_gammel 4y ago
  In JSON everything that is not map or array is effectively an attribute. It is perfectly possible to use the same logic when defining XML schema.
raydev 4y ago
> It is so much more powerful and precise compared to Json Schema. Maybe so, but the continuing popularity of JSON, YAML, TOML, and recent competitors shows that developers (in general) prefer something that is both easily readable and editable by hand. Personal opinion of course, but I wouldn't call XML precise, I would call it the opposite because it's too flexible. The older I get, the more I think programming languages/markup languages/config languages should be opinionated and strict.

KingLancelot 4y ago

[dead]

fancyfredbot 4y ago

It's hard to imagine nowadays how much hype there was around XML. It was the buzzword of the day for a while. It felt as pervasive as "AI" or "blockchain" have been recently. There were many conferences on the subject, every acronym has an X for XML in there (c.f AJAX). All this for a markup language (ok, and a schema/query/transform language). It seems so weird now.

donatj 4y ago
Yes! XML was a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses XML to do it so take my money. So many businesses just screamed about XML. It was honestly kind of a bizarre furor in the early aughts.
- oblio 4y ago
  > Yes! Cryptocurrencies were a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses cryptocurrencies to do it so take my money. So many businesses just screamed about cryptocurrencies. It was honestly kind of a bizarre furor in the early 2020s.
  - seanw444 4y ago
    > Yes! Rust was a major feature / selling point of so many industry tools and services. What does it do? No idea, but it uses Rust to do it so take my money. So many businesses just screamed about Rust. It was honestly kind of a bizarre furor in the early 2020s.
- sk5t 4y ago
  Those times were all about XML and application servers like ATG Dynamo, Coldfusion, BEA, JBoss, and WebSphere, with very delicate installation procedures that probably also involved XML.
epberry 4y ago
That is crazy to think about. I wonder what this sentence will be about in another 25 years.

HdS84 4y ago

I am the only one who utterly despises namespaces in xml? Query a document with a namespace? Oh no results? Ah forgot to add the namespace... I had never a use case for namespaces, and the ones I can envision would have been better served by a property or attribute.

acdha 4y ago
Namespaces are great as a concept: I can take your standard document and extend it without any chance of conflicting in the future if you later a property or element of the same name. This is really important for interchange systems since you inevitably end up with cases where a standard format has almost but not all of the vocabulary you need. Unfortunately, namespaces as implemented in most XML tools are terrible and that's 100% the fault of the implementers. The problem is basically this: <foo xmlns:bar="http://example.org/foobarspec"> <bar:a href="baaz">hello world</bar> <foo> To a human reading that, you should be able to write a selector like /foo/bar:a or even /foo/a but as an XML parser sees the world bar is actually: {http://example.org/foobarspec}a That's an implementation detail but a shocking percentage of XML library developers did not implement a lookup mechanism to resolve it when given "bar:a". I would maintain that paying a single developer to make libxml2 suck less would have done more to help XML adoption than everything done by any XML-related standards group combined after Y2K.
PurpleRamen 4y ago
First thing I do in any XML-Parser I write: search/replace the namespaces. I know this is awful and impacts speed, but namespaces are so f*** annoying to handle with most parsers. Getting rid of them is the simplest solution for my sanity.

mLuby 4y ago

Here's how JavaScript's XSD validator works: > A (XSD) schema validator for NodeJS that uses Java to perform the actual validation. Why? Because Java can do schema validation and NodeJS cannot. https://www.npmjs.com/package/xsd-schema-validator https://www.npmjs.com/package/xsd-schema-validator <facepalm/>

schemescape 4y ago
That’s not “JavaScript’s”, that’s just a library someone published on NPM, right?
- mLuby 4y ago
  Yep. JS doesn't have a standard library so npm is the best we've got. And speaking of the best we've got, the XSD validator above is the only one I'm aware of on npm—kind of shocking given how many overall libraries there are. It speaks to the unpopularity of XSDs among web devs, which is ironic since HTML is XML.

schemescape 4y ago

Maybe someone can help me find an obscure XML feature that I’m fairly certain I didn’t imagine: Is there a way to refer to another part of the XML tree from elsewhere in the document? I vaguely recall hearing about this feature, but now I can’t seem to find it, even after skimming the spec.

oblio 4y ago
Maybe https://stackoverflow.com/a/29371226/1320143 https://stackoverflow.com/a/29371226/1320143 ?
- schemescape 4y ago
  That’s it. Thanks! Edit: id/idref

jillesvangurp 4y ago

XML basically came out of SGML which had its origins in GML, which dates back to the 1960s. With XML they sort of dropped all the hard/difficult bits and used it as a simpler serialization format for tree shaped stuff. That happened after people got annoyed with another vaguely SGML inspired thing called HTML which of course was a bit lacking in specification and uniformity at the time. Which is why this whole thing came out of w3.org. So XML was specified and then right along came XHTML 1.0 and later 1.1, which was just whatever HTML 4 was supposed to be (Netscape, Opera, Microsoft, etc. had some conflicting points of view on this) but in well formed XML shape. Of course XHTML became a bit of a problem when it turned out that browsers had to deal with mostly not so well formed HTML coming from servers. People were just slapping whatever header on top of their html to trick browsers into various parsing modes. Eventually, the whole notion was dropped with HTML 5 just standardizing all the not so well formed bits in a way that browsers could make sense of. The WhatWG was responsible for that one. When it became clear that was the only HTML/CSS interpretation that still mattered, it was grandfathered into the w3.org and since then people have stopped talking about xhtml as a thing to pursue. Around the same time the w3c lost the plot a little bit and went off and built a whole sandcastle of standards on top of XML that mostly did not get a whole lot of traction. Capital S Semantic Web vs. lower case semantic web became a thing. One was a new web reimagined on things like SOAP, XHTML, RDF, and whole lot of other things. The other was web 2.0 featuring things like RSS (almost but not quite well formed xml, depending on where you got it), micro formats, hashtags, and a whole lot of people doing rather hacky things with wordpress, php, and related things. Then AJAX became a thing when MS added XmlRpcRequest. Soon, people figured out that this stuff just got a whole lot easier if you send Json over that instead of XML. Much easier to parse from Javascript for example.

goto11 4y ago
> thing called HTML which of course was a bit lacking in specification and uniformity at the time. HTML was actually pretty well specified except for one crucial omission: How a user agent should treat invalid HTML. XML simply declared that a user agent should stop processing and report an error - something you can get away with when you don't need to worry about backwards compatibility. Unfortunately this left XHTML dead in the water.

spapas82 4y ago

Recently I had to convert a bunch of well structured XMLs to csvs (flattening). I downloaded the apache xalan-c (xslt engine) and xerces-c(xml engine) windows binaries from 2004 (!) and to my surprise they worked fine on windows 10. After that it was half an hour work to write a quick XSLT and convert the XML to CSV. I know that there are other (even easier) ways to extract data from an XML but I have to admit that writing an XSL transformer and see if working gives me joy. Probably I'm getting too old remembering the old days...

bane 4y ago

There's lots of comments here on XML as a file format, but that's not precisely correct (even the opening of the wikipedia article on it has the same conceptual flaw in the opening description). I think understanding what it actually is, and why it exists can really offer a lot of perspective. As somebody who lived through the emergence of XML (and HTML) from SGML, and remembers SGML actually in use in some settings, I think it's important. XML is a specification for how to create data interchange formats using a semantic, hierarchical, organizational scheme -- it's not a file format. You create data formats that follow XML, but every different schema is a different data format. What XML did, and the reason it was important, was that it made it much easier to design and specify data formats that had standard tooling for writing, validating, and reading, than pretty much any other earlier conceptualization. Before then, pretty much every piece of software, and even every different version of the same software, had a custom, usually binary, undocumented, and proprietary data format that it used to serialize data (usually as a file format on disk) or to transmit data across a network. Today, it's more or less assumed that when you serialize data to disk, or build up some data object to send over a network, it'll probably be in some kind of human readable format, figuring out how to encode your data into bits, or dump out serialized C structs or whatever isn't the common practice anymore. Even using binary serialization format like Cap'n_Proto or BSON is considered kind of unusual outside of some large organizations. Developers back in those days were dealing with a variety of CPU and memory architectures, endianness, word size, and other things that made cross-platform movement of data a total nightmare. And almost nobody documented their formats in any way, reverse engineering formats was a valuable skill in some contexts. There was some precedent for XML-like approaches. A very common one was CSV, which was often used to move tabular data between systems (and is useful to view as another "specification" for making data formats). But again, it lacks a standard specification, lacks validation, and has other flaws that make it frustrating to use for data interchange. When XML hit, it was kind of like the enlightenment happened. Developers suddenly had tooling and standards that let them not only pump out data formats in a self describing way, but schemas that also let them know they were writing the data correctly and let readers know how to parse it. Even better, a human can usually just open up a data format created to the XML specification in a text editor and just read-off the data fields and values. Long-term archival became easier, networking systems became easier, RPC and API development became almost trivial, and so on. SOAP was created because XML was created. Most of Java's built in data format stuff and RPC functionality assumes XML. Thousand page books written by a dozen authors showed up in stores trying to explain to developers all of the weird edge bits and use-cases. Then the ugly parts of XML started to settle in. The verbosity, the overengineered bits, the lack of clarity over fields and attributes, stylistic disagreements over how to organize data using it. Turns out most developers don't want to go through the hassle of writing out the validation schemas so that was usually left unused, and then most of the tooling actually wasn't very good -- for a long time good implementations of readers/writers/validators just didn't even exist for many languages. It also turns out just handling and parsing through XML, even with decent tooling, is kind of an arcane chore. Since the early 2000s then, there's been an explosion of approaches that all have learned the lessons of XML, the good and the bad, and seek to tackle various perceived shortcomings: size, ease of use, etc. XML is an exquisite crystal castle, built using the purest most elegant thinking, over decades. It turns out most people just want good enough to get it done. So most developers it seems just serialize to JSON or JSONL, gzip it, and send it over the wire or write it to disk. If you're lucky somebody will write down the fields and expected data values in a team wiki somewhere, and off everybody goes. Gone are validators, carefully crafted hierarchical data values, schemas with carefully considered semantics. As somebody who lived through the dregs of binary formats and the heights of XML, I think this is okay. But it's good to know that XML exists if extreme formalism is still needed, and binary formats are relegated to highly niche use-cases.

acdha 4y ago

I remember being excited about XML when it first came out, since there were so many clunky languages used for configuration and data storage. That feeling lasted for a couple of years, and the 2000s were basically a long disappointment as the parts I liked were buried under huge piles of enterprise ejecta. The main lessons I've drawn looking back: 1. Tool quality matters more than it might seem, and you can't count on other people to fix your mess for you. A couple of things which come to mind were the lack of a good formatter and validator (people spent too much time on things like formatting errors, especially if they were starting with a very lenient parser and things seemed to work for a while until they hit a standard one) and also the way things like XSLT/XPath shipped major spec updates but since nobody implemented them in libxml2 most developers couldn't use them, use them in browsers, etc. 2. Usability similarly matters far more than experts think: I'm using namespaces here because in my experience that spoiled more people on XML than any other single feature. The requirement that you pedantically specify the namespace in things like XPath or XSLT meant that people couldn't write those using the values they saw in front of them without getting errors or, worse, silent data loss. This reliably tripped up even experienced users and it could have been easily avoided by making a handful of key client libraries smarter. Everyone deep in the XML community has learned and internalized this but it came up over and over and over as something users hated. 3. Continuing that theme, documentation and especially examples matter a lot for the same kind of reasons. I remember about a decade ago getting evangelized by a semweb person and evaluating a couple of the things they mentioned. The only documentation available for any of the half-dozen referenced specs were the specs themselves (which were not written targeting implementers or mutually compatible), and there were no examples which I could find which matched the current versions of the specs, worked with the few public tools, or, in a couple of cases, were even valid XML. The common thread in all of this was hubris and especially the assumption of inevitability. A lot of people were aware of these as sources of friction but seemed to assume that someone else would make better tools, train people, write good documentation, maintain examples, etc. — especially since if you were the kind of person sitting on a W3C community, these were less of a problem for you since you had the knowledge & skills to keep these from being significant impediments.

didntreadarticl 4y ago

XML vs JSON is such a fascinating topic, a clash of different approaches, academic vs practical might be one way of describing it but I'm sure there's many others. Are there any good books or essays on it? And having been there in the 90s seeing XML and thinking "they've tried to do everything and got into a big mess" (XSLT anyone?) its so satisfying to see something simple and flawed displace it.

college_physics 4y ago
> Are there any good books or essays on it? That would be a really good resource. I mean, anybody who has worked remotely with web technologies has an opinion about this topic but it would be interesting to compile an objective knowledge base and interpretation of why things evolved this way.
innocentoldguy 4y ago
I despise XML, not because it was a bad idea, but because of all the bad ways I've seen people use it. For example, I used to work at an ed-tech company that bought bubble test questions from Pearson, who provided their data in HUGE XML documents. If I remember correctly, they would do things like splitting the sentences of the test questions up so half the question was a tag attribute and the other half was an element. So, instead of just parsing questions, we'd have to parse them and then stitch them back together to make complete sentences. They did that with the answers too, I believe. So weird. The JSON format makes it harder to abuse data like my example above and it is a lot easier to parse, so I'd reach for it before XML any day.
- Thiez 4y ago
  Sounds like something that XSLT could have solved. When in doubt use more XML.
magicalhippo 4y ago
In a sense though the circle has been closed. With the latest JSON Schema spec, we were able to do a 1:1 mapping between our XSD's and JSON Schema, so now we can accept JSON as well as XMLs. For small messages though I agree JSON is smoother.

kzrdude 4y ago

I would want experiment with root structure of XML. Make it possible to have multiple root elements. One problem is that however big an XML document is, it has to be closed at the end, so it ends up as one atomic element, you can't partially parse an XML document correctly.

bawolff 4y ago
Its super common for xml parsers to support partial documents.
- mdaniel 4y ago
  and, AIUI, XMPP is based entirely around that very idea so it's not even a niche concept (well, aside from XMPP being arguably a niche protocol)
planede 4y ago
What do you mean by "partially parse"?
- didntreadarticl 4y ago
  If you imagine a log file that gets lines added to it now and then, its actually quite fiddly to do that with XML because of the closing outer tag
  - planede 4y ago
    Well, I see the awkwardness of emitting a log like that, but it's not any worse than emitting a single JSON array and waiting for that closing ']'. Both can be emitted and parsed in a streaming fashion though, but I wouldn't say that either XML or JSON is suitable for logs. Maybe NDJSON, but it's more like a hack around this limitation.
    - kzrdude 4y ago
      for json it's common to have multiple records per file. Then it's just one object per line, for example.

orra 4y ago

XML 1.0 was clearly a huge success. What I'm curious about is the seeming failure of XML 1.1. What happened there? Is it just like IPv6, in that there are too many non-upgradable legacy systems?

planede 4y ago
It's like YAML 1.2
dfox 4y ago
XML 1.1 did not "fail". It is from the start designed as slight relaxation of XML syntax rules for applications that can benefit from it, which essentially means applications running platforms where the usual encoding is not derived from ascii (eg. EBCDIC). It was never meant to be widely used.
- orra 4y ago
  Of course XML 1.1 was meant to be widely used. The design goals[1] for XML 1.1 are the same as for XML 1.0, including being "straightforwardly usable", "support[ing] a wide variety of applications", and being "easy to create". The relaxation of names in XML 1.1 is good for internationalisation[2], by not limiting names to Unicode 2.0 characters. Allowing NEL characters, as used on IBM mainframes, was not the sole motivation for XML 1.1. [1] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-origin-goals https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-origin-go... [2] https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-xml11 https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-xml11

college_physics 4y ago

Its a quarter of a century already... Enough of an empirical observation window to conclude that the way different entities choose to implement or adopt online information exchange is a tortured, highly inefficient process that is ultimately just a collection of historical accidents and technological aspects or merit are secondary On the face of it is strange that there is so much friction [0]. I will just enumerate a number of bizarre outcomes that I am aware of and I am sure there are others: * the xml web still goes strong both as-is and in large number of popular or niche-but-important domains (from html, svg to xbrl, sdmx, ...) * the semantic web (rdf, owl etc.) and making some sense of all the data exchange with metadata has gone nowhere * the API web (json) is reinventing the wheel for validation, annotation (schema etc) [0] xkcd jokes aside, people do have, in principle, strong incentives to adopt common languages and standards.

Devasta 4y ago

And here's to the next 25!

curiousgal 4y ago
I highly doubt computers will still exist in 1.551121e+25 years!
- pantulis 4y ago
  And coffee was spilled! Well played!
- didntreadarticl 4y ago
  [factorial joke]
  - oaiey 4y ago
    never explain a joke! :)

lp4vn 4y ago

XML was supposed to be a silver bullet of the myriad of ad-hoc formats for structuring documents that existed in the wild pre 2000(I got this information contested here, but that's what an old professor told me). In the XML "stack" you can find the XSL to ensure the validity of an XML document, the XPath to be a querying language, the XSLT to be a language for writing transformations, etc. I think one must at least respect XML stack vision of coherence and completeness. Then you have things like JSON where the whole wheel is being reinvented, in my opinion, for no clear purpose. You have for instance hundreds of libraries for creating a JSON schema and everything looks like a waste of time overall. Before anyone asks me, yes I have used JSON and YAML and I never could really understand why people keep recreating basic stuff like markup languages instead of sticking to whatever is available. And yes, verbosity because of the XML tag system always sounded a pretty silly argument to me.

college_physics 4y ago
> for no clear purpose performance may have been one driver, though for the "API web" which is the main use case there are better performing options than json > everything looks like a waste of time overall maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate.
- lp4vn 4y ago
  >maybe all that matters in the end is to be gainfully employed. having multiple formats and standards helps with that. when the Euro got introduced in Europe thousands of FX traders busy trading national currencies had to switch to trading real estate. Agreed.
dtech 4y ago
The reason is pretty clear, XML and its ecosystem was (is) enormously complex. When naively - but correctly - parsing introduces serious security vulnerabilities [1] you kinda have problems as a format. XML is just incredibly hard to get correct, understand, and be performant. JSON from the get-go was very easy to understand and start with so it gained the upper hand. [1] https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing https://owasp.org/www-community/vulnerabilities/XML_External...

NoboruWataya 4y ago

I actually didn't realise the spec was so young. I started using the internet around the same time as it was finalised. It's something you just assume has always been there. XML has its issues and personally I am always happy when I am dealing with an API or data source and see JSON rather than XML. However, there are a lot of cool things built on top of it. RSS is an obvious one that pretty much everyone here will appreciate. GPX is another really useful one. A lot of financial reporting is now also being standardised using XML. Even derivatives trading: https://www.fpml.org/ https://www.fpml.org/

martinclayton 4y ago
I had a similar feeling. I think it's because XML relatives HTML and SGML (GML anyone?) go so much further back.
- butlerm 4y ago
  HTML was invented in 1993, which is not that much further back. GML was invented in 1969, and SGML in 1986. I guess you could say that HTML resembles GML quite a bit with the addition of angle brackets and urls. XML on the other hand is basically SGML with a number of optional features left out.

leashless 4y ago

I worked on XML-EDI "back in the day". When I came to the blockchain (Ethereum team 2014) I had high hopes that it might provide the architectural solution to the problems with XML in terms of workflow, API endpoints, and the (infamous) failure of WSDL ("web services description language"). I wrote it up in the Ethereum launch piece here: https://medium.com/humanizing-the-singularity/by-the-end-of-this-article-youre-going-to-understand-blockchains-in-general-and-ethereum-a-next-e11df6a1d7cf https://medium.com/humanizing-the-singularity/by-the-end-of-... === quote begins === Of course, there are attempts to clarify this mess — to introduce standards and code reusability to help streamline these operations and make business interoperability a fact. You can choose from EDI, XMI-EDI, JSON, SOAP, XML-RPC, JSON-RPC, WSDL and half a dozen more standards to assist your integration processes. Needless to say, the reason there are so many standards is because none of them work properly. Finally, there is the problem of scaling collaboration. Say that two of us have paid the upfront costs of collaboration and have achieved seamless technical harmony, and now a third partner joins our union. And now a fourth, and a fifth. By five partners, we have 13 connections to debug. Six, seven… by ten the number is 45. The cost of collaboration keeps going up for each new partner as they join our network, and the result is small pools of collaboration which just will not grow. Remember, this isn’t just an abstract problem — this is banking, this is finance, medicine, electrical grids, food supplies, and the government. Our computers are a mess. === quote ends === My company uses XML in a sort of "semantic web" paradigm to describe products, and links to these documents from smart contracts to provide accurate machine-readable descriptions of things which are for sale. It works reasonably well, and maybe it'll turn into something a lot more powerful as operations expand. So we do walk the talk to some degree.

mrgriscom 4y ago

Always a classic: http://harmful.cat-v.org/software/xml/s-exp_vs_XML http://harmful.cat-v.org/software/xml/s-exp_vs_XML

goto11 4y ago
If there is an argument beneath the hyperbole and i-am-very-smart posturing, it seem very weak. He end up advocating a binary format (like TCP/IP) instead of a text-based like XML because it will be faster to parse. And because a binary format is harder to change, people will be sure to get it right the first time. Yeah right.
NoboruWataya 4y ago
> They are not identical. The aspects you are willing to ignore are more important than the aspects you are willing to accept. Robbery is not just another way of making a living, rape is not just another way of satisfying basic human needs, torture is not just another way of interrogation. And XML is not just another way of writing S-exps. There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished. Wow.

bazoom42 4y ago

XML shines at the intersection of structured documents and structured data. For pure data you can use JSON or s-expresssions but this does not work very well with more document-orinted data. There is a reason frontend frameworks use HTML templates or JSX even though js supports JSON natively.

crabbone 4y ago
Why do people advocate for JSON so much? It's simple, I can see that, but it also got most of its stuff wrong. If I had a liberty to choose a format in which I want to receive data, JSON would've been very much down on the list. These are just the problems that actually bit me in my professional use of JSON, not some theoretical possibilities: * No bounds on how big integers may be, subsequently, an ambiguity about what to do if the number is bigger than what would be considered a typical integer size for the platform: should it be interpreted as a float or as an integer? In my case, I had ids coming from a database that used 128-bit to represent them and the client side silently converted them to floats, but, on the way back, converted them to integers again, which resulted in rare collisions and lost data. * No defined semantics for repeated keys in hash-tables. I used a library that tried to stream JSON in SAS-like way, but the authors didn't realize that duplicate keys are a possibility. Again, this caused subtle and hard to identify data integrity issues. * Unnecessary null value. For some languages null and false are the same thing (and I prefer it that way too), but converting data back and forth between JSON and language-native data would sometimes produce inconsistent results, and, again, caused a once-in-a-year case of data integrity issue. * Mandatory Unicode string encoding. Caused problems with DICOMs from East Asia. DICOMs have some special encodings that can have characters not representable in Unicode. You can guess that I've learned it the hard way too. And there isn't a way to transfer raw data (of course, you can Base64 encode it etc. but that's not a function of the format, the parties need to agree on format extension in order to understand that).
- rwmj 4y ago
  JSON sucks as a format. You forgot to mention the lack of optional commas, and the need to quote keys. However 'jq' is absolutely great, and that unfortunately is why we used it for some command line tools that had to output structured data.

tragomaskhalos 4y ago

As someone who has circled back into Java land recently after a number of years away, it is startling the extent to which the use of XML in this environment has boiled away to nearly nothing (the only XML file in our projects is the Maven POM), when these languages were once joined at the hip. The addition of annotations into Java has been a game-changer here, but also related ecosystems like OpenApi are using Json and even Yaml in preference.

funcDropShadow 4y ago
> but also related ecosystems like OpenApi are using Json and even Yaml in preference. And that explodes my mind. Yaml is such a steaming pile of shit compared to Json, let alone XML. Yaml is the perfect example for the dichotomy of easiness versus simplicity. At first glance, it looks so easy. No tags, no braces, no commas, you can use comments. It seams to be so much better than XML and Json. After a while you begin to realize that the easiness is only perceived at first glance. In truth it is agglomeration of corner cases that got hyped like crazy. See https://noyaml.com https://noyaml.com or the top answer here https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-in-yaml-over-multiple-lines?noredirect=1&lq=1 https://stackoverflow.com/questions/3790454/how-do-i-break-a... for examples why I have such a strong opinion of Yaml.
- ElectricalUnion 4y ago
  My guess is yaml triggers exactly the same initial response as jquery; it's surface seems "small", "simple" and "intuitive", but once you need to actually do things and dig deeper on how it is implemented, you often wish you haven't used it.
  - acdha 4y ago
    I don't think that's fair to jQuery.
- planede 4y ago
  YAML fucked up bad with 1.1 and YAML 1.2 has virtually no adoption. It could have been great.