7 ms·

Don't Invent XML Languages (2006)

48 points by MrVandemar 3y ago

435345345 3y ago
I don't even know why we have any *ML. Everything they can do can be done with Lisp-syntax better.
- sanxiyn 3y ago
  S-expression still needs a schema. Just as you can't say "use XML", neither you can say "use S-expression". Most of work of defining DocBook is about defining DocBook schema, not about defining DocBook XML syntax.
- otabdeveloper4 3y ago
  XML is a document markup language. As in, articles and books n stuff. How in hell is that comparable to anything "Lisp-syntax"?
  - fiddlerwoaroof 3y ago
    There's plenty of history of s-expression formats for documentation. One example is: https://github.com/Clozure/ccl/tree/master/doc/manual https://github.com/Clozure/ccl/tree/master/doc/manual But, also, there's plenty of uses of XML that are not "artcles and books". For example, Maven's pom.xml and log4j2.xml.
  - lelanthran 3y ago
    Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages, and even of JSON-like representations. IOW, if you take Lisp expressions, add cosmetic syntactical changes like angle brackets and closing tags, then remove about 90% of functionality and cripple what's left, you'll have XML. Cripple it further and you'll have JSON.
    - quonn 3y ago
      What you call crippling is what makes JSON easy to work with and universally adopted.
      - lelanthran 3y ago
        > What you call crippling is what makes JSON easy to work with and universally adopted. For some specific tasks, certainly. A tool I am developing for myself cripples the input format even more, because the more reduced the input is the easier it is to use for a specific task. Could I have used a more powerful format? Sure, but then a format that allows too much is harder to use (especially when those extra features aren't needed). The scope of the input should match the scope of the problem. I was only pointing out that, at the highest level, the format that allows everything is Lisp s-expressions. Everything else is a less-abled form of s-expressions. Some of those formats would have been best served by simply being s-expressions instead (like XML), while others (like JSON) serve a different purpose and don't need all those extra features.
    - jeeeb 3y ago
      > Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages I don’t really follow this. What makes s-expressions a superset of markup languages? What can’t you express in XML that you can with s-expressions?
  - kitd 3y ago
    Both have ASTs are just a DAG of nodes. The only difference is what they look like in human-readable form, and how people expect to use them.
- phlakaton 3y ago
  This argument has been made in one form or another for decades. There are good reasons it hasn't prevailed. S-expressions are clumsier at expressing semistructured data that is primarily strings, which is what markup languages were designed for. Whether you think S-expressions are superior probably depends on the use case you have in mind. And there's a good chance it's not the use case you should be optimizing for.
greenyoda 3y ago
Another standardized XML language that the article doesn't mention is RDF: https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework
- omoikane 3y ago
  RDF is listed on the linked page ("known XML languages"): https://xml.coverpages.org/xmlApplications.html https://xml.coverpages.org/xmlApplications.html SVG and MathML are also listed there, both of which seemed to be used a fair bit.
- lolive 3y ago
  FYI, RDF transports graph data, where nodes MUST have a unique ID, where relationships MUST be typed, and nodes can optionally be typed. RDF has several serializtion format, one of them being XML. A binary format also exist. And the most convenient one to generate, read and understand is (imho) Turtle, aka TTL).
  - lolive 3y ago
    I have never understood why RDF (especially TTL) has never become the format of choice for data exchange. XML and JSON are usually sending connected data (:graphs), and there are very inconvenient at doing that (being tree-structured).
userbinator 3y ago
2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and needlessly-introduced-failures of string handling.
- joshlk 3y ago
  I’m sure it’s down to use case and circumstances but I frequently find it useful to be able to read and edit text based data formats (JSON/YAML/TOML). If you are concerned about data size you can easily use on-the-fly compression at little cost nowadays.
- devjab 3y ago
  In my experience people read the JSON output of things more often than anything else in both development and in maintenance. You can certainly make a point about that being stupid, and it certainly also is stupid. It just seems to be what happens when you have a gazillion APIs and even more business processes and a lot of people who should know what they are doing, who don’t. I recently had the joy of reverse engineering a terrible piece of JavaScript which created a vast and ridiculously complicated JSON delivery for one of our most important frontends. It was so full of any assumptions that the original author had several functions which were still doing various things with “unknown” because the data which had once been there wasn’t. Anyway, since I had to reverse engineer it from terrible code and no documentation I figured I’d just talk with the people who worked the data inputs and outputs and maybe learn something about the process from their business processes. Turns out they couldn’t help, what was even worse was how the frontend partner we were delivering the JSON to couldn’t even explain why they needed it the way it arrived. Those were some “fun” sessions trying to Sherlock Holmes out of the mess. This was a bad story, but it’s just one out of a thousand such stories in enterprise and non-tech IT. I think the reason JSON “won” over XML was the ”same” human reason. I’ve seen a lot of XML, but I don’t think I’ve ever seen some that didn’t break its own standards. Like you’d get all XML with data between ><‘s and then suddenly a single field would have the data inside the <… value=“”>… because duck you, or whatever else. Often they wouldn’t bother supplying you with schemas, or if they did, their auto-generated schemas wouldn’t have been updated in five years because apparently someone forgot that. Then once you “progress” beyond the technical funzies you’ll still have to deal with using the XML to find out what the hell is going on, and since it’s much harder to read (not entirely sure why) you’ll have to first convert it into JSON anyway, before whatever business process person has to read it.
joshlk 3y ago
Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?
- jszymborski 3y ago
  I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages. I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...
  - kstrauser 3y ago
    We’d all been burned on enterprisey balls of mud like XMLRPC and then SOAP. When JSON-over-HTTP came along, it was a breath of fresh air. Look, it’s readable! It’s easy to parse! It’s trivial to generate! It only had like 5% of XML’s features, but that was the point. Mere humans could read it and there was no temptation to stick something in an attribute instead of a value. Seriously, it was revelatory. Edit: Also, lots of common computer interactions — I’d go so far as to say most of them — are only passing around a few values in a simple data structure. JSON’s good for that. I wouldn’t want to necessarily use JSON to represent an office document, but that’s not what I want to use it for. “Hey API server, give me information about song 1234.” “OK, that’s ’Hotel California’ by The Eagles.” You can definitely describe both question and answer with XML, complete with schemas and all, but does that get you anything over {“name”:”Hotel California”,…}? Not really. Consider how much you can accomplish with POSIX, and it doesn’t even have named arguments. There are times when XML’s complexity is a benefit (I guess; I’ve never seen one but I don’t doubt they exist). Most of the time, it’s just overhead for the sake of overhead.
  - damagednoob 3y ago
    I think the reason that JSON won was that at least on the client-side, it was much easier to turn the response data into a Javascript object to interact with then XML.
- 3y ago
oliviergg 3y ago
I still remember working briefly in 2008 with a thing called Magic (now uniPaas I think) XML all way down. Even the code : each line was a XML . You were supposed to code with a weird GUI. Still have nightmares
- anonzzzies 3y ago
  I liked magic actually. Mostly because many other things were worse. Table driven development or something it was called? Works for my brain.
lpapez 3y ago
Thankfully we've moved on and no longer invent XML languages. We use YAML now which is obviously much better.
- hun3 3y ago
  Norway. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
- ansgri 3y ago
  There are probably as many people that recognize the sarcasm as those that honestly think so.
- deleted 3y ago
  [deleted]
account-5 3y ago
This is less about hating on XML and more about not reinventing the wheel. I quite like XML. Things like xpath make working with it, or getting data from it much easier than JSON; though I love jq syntax and can't wait until it starts being incorporated into languages. I don't even mind xslt provided it's not being over used.
- masklinn 3y ago
  > I quite like XML. Things like xpath make working with it XPath is great. 1.0 anyway, after that everything but the new functions was nonsense. But do note: XPath is not an xml dialect, it’s a non-XML DSL being applied to documents.
  - account-5 3y ago
    That makes sense about xpath not being an XML dialect. Its much easier than .NextSibling.ParentNode... etc etc. I always try to go for the path of least resistant.
    - masklinn 3y ago
      > That makes sense about xpath not being an XML dialect. But the point is that it follows TFA's advice: while it's a DSL for working with XML, it's not an XML language. Wish that XSLT had been the same, it could have been so much better. > Its much easier than .NextSibling.ParentNode... etc etc. I don't think that has any relation. Also it does look a lot like what you wrote: ./following-sibling::*[position()=1]/parent::* even if you use the various shortcuts, since there is none for the next sibling or following siblings: ./following-sibling::*[1]/..
- unwind 3y ago
  Tim Bray [1] is a co-author of the original XML spec so he is probably not hating on XML so much, no. [1]: https://en.m.wikipedia.org/wiki/Tim_Bray https://en.m.wikipedia.org/wiki/Tim_Bray
  - 3y ago
simpaticoder 3y ago
If you squint at XML, JSON, or YAML you see a kind of lispy data-structure shape, an n-arry tree. The reader has a context stack that they are pushing and popping from as they read. The real problem is that every problem space is isomorphic to one that has successively tighter context. And a format that is applicable to every problem is one that is applicable to no problem. I believe that computer languages must get worse at some things to get better at others in a zero-sum way. Any attempt to avoid this trade-off leaves you with a very powerful mush.
- wodenokoto 3y ago
  No, xml is inherently different. It’s a mark up language unlike the others which are data languages. In xml you can nest data inside of data. In json you can have data structures that can hold data. Eg., `<tag>lorem <tag2>ipsum</tag2>.</tag>` is not a thing in the others.
  - simpaticoder 3y ago
    Your example shows taking a subset of a text node and wrapping in a tag. How many XML languages use this quality? The only ones I've ever worked with go to great lengths to not mix text nodes with other children nodes. And it's easy to see why such usage is considered poor practice: if you're making a language, you generally want more structure, not less. I'm not familiar with the distinction between 'markup languages' and 'data languages'. Ignoring the text/structured mixing issue, which I think is vestigial in XML and unused in DSLs, these are all isomorphic to each other and can nest data inside of data in a similar way: <person> <name>John Doe</name> <age>30</age> <city>New York</city> <employment> <position>Software Engineer</position> <company>ABC Tech</company> <years>5</years> </employment> </person> { "person": { "name": "John Doe", "age": 30, "city": "New York", "employment": { "position": "Software Engineer", "company": "ABC Tech", "years": 5 } } } person: name: John Doe age: 30 city: New York employment: position: Software Engineer company: ABC Tech years: 5
jiggawatts 3y ago
I love listening to young developers guess at the history of XML, and why it was "complex" (it wasn't), and then turn around an reinvent that wheel, with every bit of complexity that they just said they didn't like... because it's necessary. So a bit of history from someone who was already developing for over a decade when XML was the new hotness: The before times were bad. Really bad. Everybody and everything had their own text-based formats.[1] I don't just mean a few minor variants of INI files. I mean wildly different formats in different character encodings, which were literally never provided. Niceties like UTF-8 weren't even dreamt of yet. Literally every application interpreted their config files differently, generated output logs differently, and spoke "text" over the network or the pipeline differently. If you need to read, write, send, or receive N different text formats, you needed at least N parsers and N serializers. Those parsers and serializers didn't exist. They just didn't. The formats were not formally specified, they were just "whatever some program does"... "on some machine". Yup. They output different text encodings on different machines. Or the same machine even! Seriously, if two users had different regional options, they might not be able to share files generated by the same application on the same box. Basically, you either had a programming "library" available so that you could completely sidestep the issue and avoid the text, or you'd have to write your own parser, personally, by hand. I loooved the early versions of ANTLR because they made this at least tolerable. Either way, good luck handling all the corner-cases of escaping control characters inside a quoted string that also supports macro escapes, embedded sub-expressions, or whatever. Fun times. Then XML came along. It precisely specified the syntax, and there were off-the-shelf parsers and generators for it in multiple programming languages! You could generate an XML file on one platform and read it in a different language on another by including a standardised library that you could just download instead of typing in a parser by hand like an animal. It even specified the text encoding so you wouldn't have to guess. It was glorious. Microsoft especially embraced it and to this day you can see a lot of that history in Visual Studio project files, ASP.NET web config files, and the like. The reason JSON slowly overtook XML is many-fold, but the key reason is simple: It was easier to parse JSON into JavaScript objects in the browser, and the browser was taking off as an application developer platform exponentially. JavaScript programmers outnumbered everyone else combined. Notably, the early versions of JSON were typically read using just the "eval()" function.[2] It wasn't an encoding per-se, but just a subset of JavaScript. Compared to having to have an XML parser in JavaScript, it was very lightweight. In fact, zero weight, because if JavaScript was available, then by definition, JSON was available. The timeline is important here. An in-browser XML parser was available before JSON was a thing, but only for IE 5 on Windows. JSON was invented in 2001, and XMLHttpRequest become consistently available in other browsers after 2005 and was only a standard in 2006. Truly universal adoption took a few more years after that. XML was only "complex" because it's not an object-notation like JSON is. It's a document markup language, much like HTML. Both trace their roots back to SGML, which dates back to 1986. These types of languages were used in places like Boeing for records keeping, such as tracking complex structured and semi-structured information about aircraft parts over decades. That kind of problem has an essential complexity that can't be wished away. JSON is simpler for data exchange because it maps nicely to how object oriented languages store pure data, but it can't be readily used to represent human-readable documents the way XML can. The other simplification was that JSON did away with schemas and the like, and was commonly used with dynamic languages. Developers got into the habit of reading JSON by shoving it into an object, and then interpreting it directly without any kind of parsing or decoding layer. This works kinda-sorta in languages like Python or JavaScript, but is horrific when used at scale. I'm a developer used to simply clicking a button in Visual Studio to have it instantly bulk-generate entire API client libraries from a WSDL XML API schema, documentation and all. So when I hear REST people talk about how much simpler JSON is, I have no idea what they're talking about. So now, slowly, the wheel is being reinvented to avoid the manual labour of RETS and return to machine automation we had with WS-*. There are JSON API schemas (multiple!), written in JSON (of course), so documentation can't be expressed in-line (because JSON is not a markup language). I'm seeing declarative languages like workflow engines and API management expression written in JSON gibberish now, same as we did with XML twenty years ago. Mark my words, it's just a matter of time until someone invents JSON namespaces... [1] Most of the older Linux applications still do, which makes it ever so much fun to robustly modify config files programatically. [2] Sure, these days JSON is "parsed" even by browsers instead of sent to eval(), for security reasons, but that's not how things started out.
megaperplex 3y ago
The author makes an argument against designing new XML languages. I think his arguments are weak. This does not mean I think we should design more XML languages, but that the arguments this particular author brings against it are weak. That having be said, the mid section with the tooling suggestions by use case is neat. One thing he condemns such endeavors for is that it is unpleasant and somehow "political". I can see what he means, but this has nothing to do with "overdoing the extensibility" of XML. As Aaron Schwartz put it "Instead of the "let's just build something that works" attitude that made the Web (and the Internet) such a roaring success, they brought the formalizing mindset of mathematicians and the institutional structures of academics and defense contractors. They formed committees to form working groups to write drafts of ontologies that carefully listed (in 100-page Word documents) all possible things in the universe and the various properties they could have, and they spent ours in Talmudic debates over whether a washing machine was a kitchen appliance or a household cleaning device. [https://www.cs.rpi.edu/~hendler/ProgrammableWebSwartz2009.html https://www.cs.rpi.edu/~hendler/ProgrammableWebSwartz2009.ht...]" It is true that similar endeavors are prone to looking for an Absolute Cosmic Eternal Perfect Ontological Structure (credit: Lion Kimbro). If you drop that idea in any office, you will get as many proposals for entities as there are anuses, as if anyone is entitled to an ontology. Don't get me wrong, anyone might be entitled to submit an entity or criticize a hierarchy, but I think this is meaningful mostly in the context of targeted audience research and agile development practices. All in all, I think that the problem here is not with the 'X' in XML, but with poor organization-level practices. Furthermore, I did follow the link and surveyed the XML languages. I did not see the apparently self-evident truth the writer sees in there. Sure, there are many of them, but how is this even an argument? Some of the listed languages seem quite cool to me, especially the science ones. And the next person might dig the legal ones. If the argument here is that "there are so many of them languages, they just can all be important" (or "real") does not sit well with me. There are tons of different programming languages, web frameworks, linux distributions, not to mention the incomprehensible multitude in other domains, such as car maker models or, well, birds. It is just simplistic to disparage any number of things because they are too many to make readily sense of, and this is a cognitive stance I can't endorse. Look at Medical Subject Headings, or the Dewey Decimal or the Library of Congress cataloging systems. There is just a ton of things out there and for each one of those, there is a person that has more expertise on than yourself. These taxonomies might be important to them, what are you gonna do? Stop them? A bird's view exasperation of the sheer number of things is the hallmark of a small town mentality that is untenable for the hacktivist mindset. The response here is, I guess, reusability of existing standards, and agile practices involving the user in the development process. But the author did not bring up any of these.
dkersten 3y ago
I still see people, in 2024, writing new software and using XML as the data format. I don't have an example offhand, but I recently saw a hobby game engine using XML to store its engine-specific game object/scene data. Personally, I like to use TOML for anything that is likely to also be edited by humans and JSON or binary for something that will only ever be used by machines.
- freedomben 3y ago
  in the Java world? I've seen a couple XMLs on newer software but all from Java ecosystem, where there are substantial libraries in existence and the authors are already super familiar with it to the point where it's basically "free" Everything else is YAML, JSON, or TOML (especially in the rust world)
  - dkersten 3y ago
    > in the Java world? No. The most recent one I saw was a (hobbyist) C++ game engine that used XML to declare game entities and such.
- novagameco 3y ago
  I like to use XML for UI markup, similar to html
- CharlesW 3y ago
  > I still see people, in 2024, writing new software and using XML as the data format. Because it's a pragmatic choice with a large, mature, proven ecosystem. (Not that there's anything wrong with TOML for INI-type use cases.) I think some readers are missing the point of Tim's article. He's not saying "don't use XML" — he's saying "don't invent XML languages…unless you have to". > "The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom." Presumably, he'd recommend using RSS and OPML as well if those fit your use case.
calvinmorrison 3y ago
I hate xml.
- qznc 3y ago
  I hate json.
  - bbkane 3y ago
    I hate
    - ioasuncvinvaer 3y ago
      I
deleted 3y ago
[deleted]
maxrecursion 3y ago
I used the OVAL "Open source Vulnerability Assessment Language", written in XML, daily to automate STIGs. Finding documentation for it was awful, but once I knew the syntax development was a breeze. Most chill job I ever had. A job like that is my retirement plan once I have enough money that salary no longer matters.

48 points by MrVandemar 3y ago

435345345 3y ago

I don't even know why we have any *ML. Everything they can do can be done with Lisp-syntax better.

sanxiyn 3y ago
S-expression still needs a schema. Just as you can't say "use XML", neither you can say "use S-expression". Most of work of defining DocBook is about defining DocBook schema, not about defining DocBook XML syntax.
otabdeveloper4 3y ago
XML is a document markup language. As in, articles and books n stuff. How in hell is that comparable to anything "Lisp-syntax"?
- fiddlerwoaroof 3y ago
  There's plenty of history of s-expression formats for documentation. One example is: https://github.com/Clozure/ccl/tree/master/doc/manual https://github.com/Clozure/ccl/tree/master/doc/manual But, also, there's plenty of uses of XML that are not "artcles and books". For example, Maven's pom.xml and log4j2.xml.
- lelanthran 3y ago
  Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages, and even of JSON-like representations. IOW, if you take Lisp expressions, add cosmetic syntactical changes like angle brackets and closing tags, then remove about 90% of functionality and cripple what's left, you'll have XML. Cripple it further and you'll have JSON.
  - quonn 3y ago
    What you call crippling is what makes JSON easy to work with and universally adopted.
    - lelanthran 3y ago
      > What you call crippling is what makes JSON easy to work with and universally adopted. For some specific tasks, certainly. A tool I am developing for myself cripples the input format even more, because the more reduced the input is the easier it is to use for a specific task. Could I have used a more powerful format? Sure, but then a format that allows too much is harder to use (especially when those extra features aren't needed). The scope of the input should match the scope of the problem. I was only pointing out that, at the highest level, the format that allows everything is Lisp s-expressions. Everything else is a less-abled form of s-expressions. Some of those formats would have been best served by simply being s-expressions instead (like XML), while others (like JSON) serve a different purpose and don't need all those extra features.
  - jeeeb 3y ago
    > Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages I don’t really follow this. What makes s-expressions a superset of markup languages? What can’t you express in XML that you can with s-expressions?
- kitd 3y ago
  Both have ASTs are just a DAG of nodes. The only difference is what they look like in human-readable form, and how people expect to use them.
phlakaton 3y ago
This argument has been made in one form or another for decades. There are good reasons it hasn't prevailed. S-expressions are clumsier at expressing semistructured data that is primarily strings, which is what markup languages were designed for. Whether you think S-expressions are superior probably depends on the use case you have in mind. And there's a good chance it's not the use case you should be optimizing for.

greenyoda 3y ago

Another standardized XML language that the article doesn't mention is RDF: https://en.wikipedia.org/wiki/Resource_Description_Framework https://en.wikipedia.org/wiki/Resource_Description_Framework

omoikane 3y ago
RDF is listed on the linked page ("known XML languages"): https://xml.coverpages.org/xmlApplications.html https://xml.coverpages.org/xmlApplications.html SVG and MathML are also listed there, both of which seemed to be used a fair bit.
lolive 3y ago
FYI, RDF transports graph data, where nodes MUST have a unique ID, where relationships MUST be typed, and nodes can optionally be typed. RDF has several serializtion format, one of them being XML. A binary format also exist. And the most convenient one to generate, read and understand is (imho) Turtle, aka TTL).
- lolive 3y ago
  I have never understood why RDF (especially TTL) has never become the format of choice for data exchange. XML and JSON are usually sending connected data (:graphs), and there are very inconvenient at doing that (being tree-structured).

userbinator 3y ago

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and needlessly-introduced-failures of string handling.

joshlk 3y ago
I’m sure it’s down to use case and circumstances but I frequently find it useful to be able to read and edit text based data formats (JSON/YAML/TOML). If you are concerned about data size you can easily use on-the-fly compression at little cost nowadays.
devjab 3y ago
In my experience people read the JSON output of things more often than anything else in both development and in maintenance. You can certainly make a point about that being stupid, and it certainly also is stupid. It just seems to be what happens when you have a gazillion APIs and even more business processes and a lot of people who should know what they are doing, who don’t. I recently had the joy of reverse engineering a terrible piece of JavaScript which created a vast and ridiculously complicated JSON delivery for one of our most important frontends. It was so full of any assumptions that the original author had several functions which were still doing various things with “unknown” because the data which had once been there wasn’t. Anyway, since I had to reverse engineer it from terrible code and no documentation I figured I’d just talk with the people who worked the data inputs and outputs and maybe learn something about the process from their business processes. Turns out they couldn’t help, what was even worse was how the frontend partner we were delivering the JSON to couldn’t even explain why they needed it the way it arrived. Those were some “fun” sessions trying to Sherlock Holmes out of the mess. This was a bad story, but it’s just one out of a thousand such stories in enterprise and non-tech IT. I think the reason JSON “won” over XML was the ”same” human reason. I’ve seen a lot of XML, but I don’t think I’ve ever seen some that didn’t break its own standards. Like you’d get all XML with data between ><‘s and then suddenly a single field would have the data inside the <… value=“”>… because duck you, or whatever else. Often they wouldn’t bother supplying you with schemas, or if they did, their auto-generated schemas wouldn’t have been updated in five years because apparently someone forgot that. Then once you “progress” beyond the technical funzies you’ll still have to deal with using the XML to find out what the hell is going on, and since it’s much harder to read (not entirely sure why) you’ll have to first convert it into JSON anyway, before whatever business process person has to read it.

joshlk 3y ago

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

jszymborski 3y ago
I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages. I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...
- kstrauser 3y ago
  We’d all been burned on enterprisey balls of mud like XMLRPC and then SOAP. When JSON-over-HTTP came along, it was a breath of fresh air. Look, it’s readable! It’s easy to parse! It’s trivial to generate! It only had like 5% of XML’s features, but that was the point. Mere humans could read it and there was no temptation to stick something in an attribute instead of a value. Seriously, it was revelatory. Edit: Also, lots of common computer interactions — I’d go so far as to say most of them — are only passing around a few values in a simple data structure. JSON’s good for that. I wouldn’t want to necessarily use JSON to represent an office document, but that’s not what I want to use it for. “Hey API server, give me information about song 1234.” “OK, that’s ’Hotel California’ by The Eagles.” You can definitely describe both question and answer with XML, complete with schemas and all, but does that get you anything over {“name”:”Hotel California”,…}? Not really. Consider how much you can accomplish with POSIX, and it doesn’t even have named arguments. There are times when XML’s complexity is a benefit (I guess; I’ve never seen one but I don’t doubt they exist). Most of the time, it’s just overhead for the sake of overhead.
- damagednoob 3y ago
  I think the reason that JSON won was that at least on the client-side, it was much easier to turn the response data into a Javascript object to interact with then XML.
3y ago

oliviergg 3y ago

I still remember working briefly in 2008 with a thing called Magic (now uniPaas I think) XML all way down. Even the code : each line was a XML . You were supposed to code with a weird GUI. Still have nightmares

anonzzzies 3y ago
I liked magic actually. Mostly because many other things were worse. Table driven development or something it was called? Works for my brain.

lpapez 3y ago

Thankfully we've moved on and no longer invent XML languages. We use YAML now which is obviously much better.

hun3 3y ago
Norway. https://hitchdev.com/strictyaml/why/implicit-typing-removed/ https://hitchdev.com/strictyaml/why/implicit-typing-removed/
ansgri 3y ago
There are probably as many people that recognize the sarcasm as those that honestly think so.
deleted 3y ago
[deleted]

account-5 3y ago

This is less about hating on XML and more about not reinventing the wheel. I quite like XML. Things like xpath make working with it, or getting data from it much easier than JSON; though I love jq syntax and can't wait until it starts being incorporated into languages. I don't even mind xslt provided it's not being over used.

masklinn 3y ago
> I quite like XML. Things like xpath make working with it XPath is great. 1.0 anyway, after that everything but the new functions was nonsense. But do note: XPath is not an xml dialect, it’s a non-XML DSL being applied to documents.
- account-5 3y ago
  That makes sense about xpath not being an XML dialect. Its much easier than .NextSibling.ParentNode... etc etc. I always try to go for the path of least resistant.
  - masklinn 3y ago
    > That makes sense about xpath not being an XML dialect. But the point is that it follows TFA's advice: while it's a DSL for working with XML, it's not an XML language. Wish that XSLT had been the same, it could have been so much better. > Its much easier than .NextSibling.ParentNode... etc etc. I don't think that has any relation. Also it does look a lot like what you wrote: ./following-sibling::*[position()=1]/parent::* even if you use the various shortcuts, since there is none for the next sibling or following siblings: ./following-sibling::*[1]/..
unwind 3y ago
Tim Bray [1] is a co-author of the original XML spec so he is probably not hating on XML so much, no. [1]: https://en.m.wikipedia.org/wiki/Tim_Bray https://en.m.wikipedia.org/wiki/Tim_Bray
- 3y ago

simpaticoder 3y ago

If you squint at XML, JSON, or YAML you see a kind of lispy data-structure shape, an n-arry tree. The reader has a context stack that they are pushing and popping from as they read. The real problem is that every problem space is isomorphic to one that has successively tighter context. And a format that is applicable to every problem is one that is applicable to no problem. I believe that computer languages must get worse at some things to get better at others in a zero-sum way. Any attempt to avoid this trade-off leaves you with a very powerful mush.

wodenokoto 3y ago
No, xml is inherently different. It’s a mark up language unlike the others which are data languages. In xml you can nest data inside of data. In json you can have data structures that can hold data. Eg., `<tag>lorem <tag2>ipsum</tag2>.</tag>` is not a thing in the others.
- simpaticoder 3y ago
  Your example shows taking a subset of a text node and wrapping in a tag. How many XML languages use this quality? The only ones I've ever worked with go to great lengths to not mix text nodes with other children nodes. And it's easy to see why such usage is considered poor practice: if you're making a language, you generally want more structure, not less. I'm not familiar with the distinction between 'markup languages' and 'data languages'. Ignoring the text/structured mixing issue, which I think is vestigial in XML and unused in DSLs, these are all isomorphic to each other and can nest data inside of data in a similar way: <person> <name>John Doe</name> <age>30</age> <city>New York</city> <employment> <position>Software Engineer</position> <company>ABC Tech</company> <years>5</years> </employment> </person> { "person": { "name": "John Doe", "age": 30, "city": "New York", "employment": { "position": "Software Engineer", "company": "ABC Tech", "years": 5 } } } person: name: John Doe age: 30 city: New York employment: position: Software Engineer company: ABC Tech years: 5

jiggawatts 3y ago

I love listening to young developers guess at the history of XML, and why it was "complex" (it wasn't), and then turn around an reinvent that wheel, with every bit of complexity that they just said they didn't like... because it's necessary. So a bit of history from someone who was already developing for over a decade when XML was the new hotness: The before times were bad. Really bad. Everybody and everything had their own text-based formats.[1] I don't just mean a few minor variants of INI files. I mean wildly different formats in different character encodings, which were literally never provided. Niceties like UTF-8 weren't even dreamt of yet. Literally every application interpreted their config files differently, generated output logs differently, and spoke "text" over the network or the pipeline differently. If you need to read, write, send, or receive N different text formats, you needed at least N parsers and N serializers. Those parsers and serializers didn't exist. They just didn't. The formats were not formally specified, they were just "whatever some program does"... "on some machine". Yup. They output different text encodings on different machines. Or the same machine even! Seriously, if two users had different regional options, they might not be able to share files generated by the same application on the same box. Basically, you either had a programming "library" available so that you could completely sidestep the issue and avoid the text, or you'd have to write your own parser, personally, by hand. I loooved the early versions of ANTLR because they made this at least tolerable. Either way, good luck handling all the corner-cases of escaping control characters inside a quoted string that also supports macro escapes, embedded sub-expressions, or whatever. Fun times. Then XML came along. It precisely specified the syntax, and there were off-the-shelf parsers and generators for it in multiple programming languages! You could generate an XML file on one platform and read it in a different language on another by including a standardised library that you could just download instead of typing in a parser by hand like an animal. It even specified the text encoding so you wouldn't have to guess. It was glorious. Microsoft especially embraced it and to this day you can see a lot of that history in Visual Studio project files, ASP.NET web config files, and the like. The reason JSON slowly overtook XML is many-fold, but the key reason is simple: It was easier to parse JSON into JavaScript objects in the browser, and the browser was taking off as an application developer platform exponentially. JavaScript programmers outnumbered everyone else combined. Notably, the early versions of JSON were typically read using just the "eval()" function.[2] It wasn't an encoding per-se, but just a subset of JavaScript. Compared to having to have an XML parser in JavaScript, it was very lightweight. In fact, zero weight, because if JavaScript was available, then by definition, JSON was available. The timeline is important here. An in-browser XML parser was available before JSON was a thing, but only for IE 5 on Windows. JSON was invented in 2001, and XMLHttpRequest become consistently available in other browsers after 2005 and was only a standard in 2006. Truly universal adoption took a few more years after that. XML was only "complex" because it's not an object-notation like JSON is. It's a document markup language, much like HTML. Both trace their roots back to SGML, which dates back to 1986. These types of languages were used in places like Boeing for records keeping, such as tracking complex structured and semi-structured information about aircraft parts over decades. That kind of problem has an essential complexity that can't be wished away. JSON is simpler for data exchange because it maps nicely to how object oriented languages store pure data, but it can't be readily used to represent human-readable documents the way XML can. The other simplification was that JSON did away with schemas and the like, and was commonly used with dynamic languages. Developers got into the habit of reading JSON by shoving it into an object, and then interpreting it directly without any kind of parsing or decoding layer. This works kinda-sorta in languages like Python or JavaScript, but is horrific when used at scale. I'm a developer used to simply clicking a button in Visual Studio to have it instantly bulk-generate entire API client libraries from a WSDL XML API schema, documentation and all. So when I hear REST people talk about how much simpler JSON is, I have no idea what they're talking about. So now, slowly, the wheel is being reinvented to avoid the manual labour of RETS and return to machine automation we had with WS-*. There are JSON API schemas (multiple!), written in JSON (of course), so documentation can't be expressed in-line (because JSON is not a markup language). I'm seeing declarative languages like workflow engines and API management expression written in JSON gibberish now, same as we did with XML twenty years ago. Mark my words, it's just a matter of time until someone invents JSON namespaces... [1] Most of the older Linux applications still do, which makes it ever so much fun to robustly modify config files programatically. [2] Sure, these days JSON is "parsed" even by browsers instead of sent to eval(), for security reasons, but that's not how things started out.

megaperplex 3y ago

The author makes an argument against designing new XML languages. I think his arguments are weak. This does not mean I think we should design more XML languages, but that the arguments this particular author brings against it are weak. That having be said, the mid section with the tooling suggestions by use case is neat. One thing he condemns such endeavors for is that it is unpleasant and somehow "political". I can see what he means, but this has nothing to do with "overdoing the extensibility" of XML. As Aaron Schwartz put it "Instead of the "let's just build something that works" attitude that made the Web (and the Internet) such a roaring success, they brought the formalizing mindset of mathematicians and the institutional structures of academics and defense contractors. They formed committees to form working groups to write drafts of ontologies that carefully listed (in 100-page Word documents) all possible things in the universe and the various properties they could have, and they spent ours in Talmudic debates over whether a washing machine was a kitchen appliance or a household cleaning device. [https://www.cs.rpi.edu/~hendler/ProgrammableWebSwartz2009.html https://www.cs.rpi.edu/~hendler/ProgrammableWebSwartz2009.ht...]" It is true that similar endeavors are prone to looking for an Absolute Cosmic Eternal Perfect Ontological Structure (credit: Lion Kimbro). If you drop that idea in any office, you will get as many proposals for entities as there are anuses, as if anyone is entitled to an ontology. Don't get me wrong, anyone might be entitled to submit an entity or criticize a hierarchy, but I think this is meaningful mostly in the context of targeted audience research and agile development practices. All in all, I think that the problem here is not with the 'X' in XML, but with poor organization-level practices. Furthermore, I did follow the link and surveyed the XML languages. I did not see the apparently self-evident truth the writer sees in there. Sure, there are many of them, but how is this even an argument? Some of the listed languages seem quite cool to me, especially the science ones. And the next person might dig the legal ones. If the argument here is that "there are so many of them languages, they just can all be important" (or "real") does not sit well with me. There are tons of different programming languages, web frameworks, linux distributions, not to mention the incomprehensible multitude in other domains, such as car maker models or, well, birds. It is just simplistic to disparage any number of things because they are too many to make readily sense of, and this is a cognitive stance I can't endorse. Look at Medical Subject Headings, or the Dewey Decimal or the Library of Congress cataloging systems. There is just a ton of things out there and for each one of those, there is a person that has more expertise on than yourself. These taxonomies might be important to them, what are you gonna do? Stop them? A bird's view exasperation of the sheer number of things is the hallmark of a small town mentality that is untenable for the hacktivist mindset. The response here is, I guess, reusability of existing standards, and agile practices involving the user in the development process. But the author did not bring up any of these.

dkersten 3y ago

I still see people, in 2024, writing new software and using XML as the data format. I don't have an example offhand, but I recently saw a hobby game engine using XML to store its engine-specific game object/scene data. Personally, I like to use TOML for anything that is likely to also be edited by humans and JSON or binary for something that will only ever be used by machines.

freedomben 3y ago
in the Java world? I've seen a couple XMLs on newer software but all from Java ecosystem, where there are substantial libraries in existence and the authors are already super familiar with it to the point where it's basically "free" Everything else is YAML, JSON, or TOML (especially in the rust world)
- dkersten 3y ago
  > in the Java world? No. The most recent one I saw was a (hobbyist) C++ game engine that used XML to declare game entities and such.
novagameco 3y ago
I like to use XML for UI markup, similar to html
CharlesW 3y ago
> I still see people, in 2024, writing new software and using XML as the data format. Because it's a pragmatic choice with a large, mature, proven ecosystem. (Not that there's anything wrong with TOML for INI-type use cases.) I think some readers are missing the point of Tim's article. He's not saying "don't use XML" — he's saying "don't invent XML languages…unless you have to". > "The smartest thing to do would be to find a way to use one of the perfectly good markup languages that have been designed and debugged and have validators and authoring software and parsers and generators and all that other good stuff. Here’s a radical idea: don’t even think of making your own language until you’re sure that you can’t do the job using one of the Big Five: XHTML, DocBook, ODF, UBL, and Atom." Presumably, he'd recommend using RSS and OPML as well if those fit your use case.

calvinmorrison 3y ago

I hate xml.

qznc 3y ago
I hate json.
- bbkane 3y ago
  I hate
  - ioasuncvinvaer 3y ago
    I

deleted 3y ago

[deleted]

maxrecursion 3y ago

I used the OVAL "Open source Vulnerability Assessment Language", written in XML, daily to automate STIGs. Finding documentation for it was awful, but once I knew the syntax development was a breeze. Most chill job I ever had. A job like that is my retirement plan once I have enough money that salary no longer matters.