6 ms·

I never could understand the hate XML got, but I'm having a bit of schadenfreude seeing what people suffer through with its replacements. An XML document with

• Jenk 4y ago
  Hard disagree. XML is great for systems to read and write, but utterly abhorrent for humans. It's not just having to close tags. It's content vs attribute confusion, namespacing noise (which are also muddled with attributes), and there's a squint factor incurred by the density of information.
  • vincnetas 4y ago
    i think that propper schema and autocompleate would save the day. even i would say make things easier. talking about XML
    • piskov 4y ago
      I’ve been using this for (schema + autocomplete) for at least 18(!) years. Moreover I even got comments on xml attributes and elements, warnings if required element is missing or required count is not met. You even got visual hierarchical collapsable UI for viewing/editing that XSD schema. I repeat: 18 years of autocomplete, comments on hover, and validation for typos/count/order for XML in Visual Studio.
      • Jenk 4y ago
        20-something years of web/app.config is the primary reason why I hate XML. Very, very closely followed by Java ("a DSL for turning XML into stacktraces") and its over complicated ecosystem of xml configurations.
        • thrwawayjan1223 4y ago
          I have worked with Java for over two decades, and your experience does not match mine. At $work there are only two XML files in each project: - logback.xml: configuring logging which is usually only done once or twice and is the same for each project. - pom.xml: Maven config which is mostly autogenerated by IntelliJ when creating a new project. I only add a few lines for new dependencies. In rare cases I may use some plugins to do specific build operations, but the actual XML is simple. Most of the time is spent on understanding the plugin itself, and not "fighting" XML. Moving this to YAML has no effect on my productivity All other configuration is either done using YAML, properties or configuration in code (Spring Boot). I see Spring still has options to use XML configurations, but I don't see any reasons why anyone would do that in 2023. The "new" standard in Spring is configuration by code, which I have done for the last 8 years. The ecosystem for Java today can not be compared to what it was 10 years ago. If editing XML configurations is still a problem at your workplace, find a new job :-) Either you work with a legacy system that nobody wants to update to the new standards, or you have architects who are stuck.
  • bambax 4y ago
    Namespacing is the opposite of noise: it lets different domains coexist with no possible confusion about which is which. But experience has taught me that trying to explain why XML is great and simple to read and write for humans, to someone who thinks differently, is useless. And so, I won't. Yet, please accept that some people, like me, really liked it and didn't mind the little quirks in light of all it offered.
    • deafpolygon 4y ago
      I disliked it intensely at first, but over time .. I now see the merit in it. I like XML, especially compared to everything else (that came after). It was possible to clearly define things.
      • Jenk 4y ago
        On the same system? I can see that. One thing I've lamented about XML for years is that it's a pain when moving to different systems that have their own namespaces/DTDs.
    • wartijn_ 4y ago
      It makes sense that explaining why xml is great doesn’t work. Maybe you can convince someone who’s never worked with xml. But if someone has used xml and thinks it’s a bad format based on those experiences, you’ll need to bring _really_ good arguments to let them think it’s a good format anyway. Just ask yourself: could a comment here convince you that xml is a bad format? If not, why would the opposite work?
      • deleted 4y ago
        [deleted]
      • lostmsu 4y ago
        Well yes, if it described a format as pleasant for humans as YAML, while not being ambigious and error-prone.
  • Ygg2 4y ago
    On the other hand XML document with good schema is pleasure to write in any decent IDE. It just autocompletes itself. I know JSON schema exist, but it never managed to just work that well.
• scott_w 4y ago
  > All that horrible mess, it seems, because people didn't like to have to close tags. The issue isn't that it's bad per-se. The issue is that it's cumbersome to write. When you want to setup and tweak a tool, it gets annoying very quickly having to deal with little errors because you misspelled a closing tag. Maybe you want to test enabling a setting? Typing out 4 characters is so much less friction than the 20 or more (including the < > : / characters) you'd need for an XML config.
  • acdha 4y ago
    It’s more typing but it’s simple typing most people don’t even think about because it’s predictable (not to mention automatic in many editors). I’d take that over the frictional cost of thinking your YAML is done and then having to debug magic data conversion or realize that you left out one character causing something to be parsed completely differently. Where XML falls down hard is tool usability. There’s still no standard formatter or good validation tool, and things like namespace support is a constant source of friction.
    • scott_w 4y ago
      > I’d take that over the frictional cost of You might but the rest of us didn't. At a visual level, YAML is really nice. The problem is when you actually want to use it for... well... anything. On the flip side, XML is downright ugly to read and write, which makes it a no-go for configuration files that are written and modified by hand.
      • acdha 4y ago
        Look, I’m not saying XML is perfect but the worthy criticism is more substantial than closing tags. It’s a very easy convention to learn requiring little thought and I haven’t used an editor which didn’t automate that process since the turn of the century. That’s less cognitive load than having to remember a bunch of context-sensitive rules about YAML’s magic behavior - I’m thinking in particular of people I know who’ve burned hours only realize that they’d missed a character somewhere, forgot to escape one value, or had an indentation issue causing something to be ignored. The criticisms I would make are more fundamental: the XML data model is different than the most popular data structures and the APIs in most languages are quite cumbersome and can lead to silent data loss (name spacing and selectors). Someone probably could have done an XML5 effort 15 years ago but by now I don’t see that happening. If I had to rank the options for a configuration language, I’d probably go HCL, TOML, JSONC, JSON, YAML + Prettier + a YAML lint schema, YAML, XML. XML could rise up with better tools but so could a low-magic YAML variant.
• donatj 4y ago
  It’s the learning curve really. Our industry has the remarkable properties of being almost entirely newbies, a constant churn of green developers, combined with being very bad about passing down generational knowledge. This is why things that are easier to explain win out over things that are technically superior but take longer to get your head around almost every time. The thing JSON had going for it over XML is that it maps cleanly to most languages object models so you can read the results directly. No writing XQueries or DOMs to read values. It’s only major downfall is lack of comments, which has lead people to YAML. (There’s plenty of other things it lacks in comparison to XML, like native schemas, but most of that falls into things newbies don’t know they want) YAML is in this weird middle place where it’s easy to explain but impossible for a human to master. It appears as simple as JSON to newcomers who adopt it, but the long time users of it find it full of foot guns. People wanted JSON with comments but instead they got the complexity of XML minus the clarity.
  • makeitdouble 4y ago
    XML is/was hated by newbies and old farts alike. Of course some of the hate come from the application where XML was used, more than XML itself, but it also is a deeply flawed language. Nowadays the main issue would be that it requires a complex generator and parser libraries to be any useful (you'll never want to deal with XML parsing/escaping by yourself) yet it's not as efficient as binary formats like protobuff for instance. That means that anything you'll want to edit by hand or be purely textual and readble will be better done in yaml or json, and anything beyond that can be done in other ways. The need for a single language trying to awkwardly span all the spectrum isn't big.
    • gpderetta 4y ago
      We all hate XML. We equally hate all replacements (as a config language) after it. At least XML stayed around long enough to have decent tooling.
• melx 4y ago
  I miss the old days of working with XSLT and XPath. A nice way of giving some design touches and filtering/sorting to XML documents. It wasn't perfect but I would take any time over the yaml/json/toml/ini.
  • bambax 4y ago
    Me too!
  • thraxil 4y ago
    I don't know if I'd say I "miss" XSLT and XPath, but yeah, it was fun and powerful at the time. I made some crazy stuff with Cocoon and AxKit that, if you didn't mind the syntax, were actually pretty elegant.
    • manbart 4y ago
      I'm surprised XQuery never became more popular, it's essentially XSLT with a 'normal' syntax
  • rwmj 4y ago
    XPath is cool (and I still use it for work regularly). jq JSON expressions seem to be inspired by it as well. XSLT was horrible though. A programming language with XML syntax, no thanks!
    • int_19h 4y ago
      XQuery gives you 90% of XSLT with a syntax that is a superset of XPath. Verbose queries (https://en.wikipedia.org/wiki/FLWOR https://en.wikipedia.org/wiki/FLWOR) are especially nice and readable.
• silvestrov 4y ago
  The really great thing about xml with XSD is the ability to validate the document really well. I.e. having content matching regexps, so you can be sure version numbers are always \d+(\.\d+)* and does not have unexpected letters or spaces in it. That date values are in ISO format. Very useful for APIs to 3rd parties as it now is very easy to catch most errors and provide an useful error message for them without having to code every check.
• makeitdouble 4y ago
  > An XML document with a well-thought-out domain-specific DTD would solve all these problems; But then a YAML document written by disciplined and well-thinking people will also not have these problems. Any of the complex formats work well when used in the most fitting way and go horribly wrong when people try to benefit too much from the complexity. XML was also a nightmare when put in the wrong hand, just as yaml is, and the next hyped and turing complete document syntax will be.
  • enw 4y ago
    If something's too easy to misuse, it's bad design.
    • makeitdouble 4y ago
      Ease to use and ease to misuse usually come hand in hand. If we had very clear and static requirements I’d see languages/tools with more safeguards, fool proofing, optimized design etc. But we’ll never have that for configuration languages, and when aiming for flexibility you have to trust people to not shoot their own feet.
• singingfish 4y ago
  XML has the hate because back in the day everyone was like "oh XML is a human and computer readable data format, that will solve all of our problems". Sure it solved all of the problems by making a data format that both humans and computers found difficult to read. "Oh I've got a problem. I'll solve it with XML. Now you have two problems" ;)
• mmis1000 4y ago
  These days, JSON also has JSON schema that allows you to enforce the structure of a JSON file. If you need a enum that only allow specific value, you just list it.
• talideon 4y ago
  The problem with XML is mainly in the 'M': it's a _markup_ language. Using it for configuration and arbitrary data serialisation isn't where its strengths lie, but it got shoved into those niches because if you look at it _just right_, you can make it work in them. I don't hate XML myself, but I do hate how it's been abused over the years.
• philjohn 4y ago
  True - but then again, writing an XML config file can be a bit of a pain as it's more verbose.
• api 4y ago
  It’s the verbosity for me. Why does everything need a fully spelled out closing tag?
  • singularity2001 4y ago
    So that in long nested data you know which tag closes what. {{{{{}}}}}
  • FpUser 4y ago
    I see nothing wrong about closing tag. Helps to navigate and understand in my opinion. I have way more problem with developers trying to be super concise and writing constructs that are very hard to parse mentally when looking at.
• acdha 4y ago
  I remember being excited when XML hit 1.0 (as a new programmer this seemed like a huge advance over things like classic Unix configuration files), and progressively disappointed over the next decade as the promise not only wasn’t delivered on. The things which killed XML seem to me to be related to the old standards culture: the people involved assumed adoption was inevitable and distracted themselves with increasingly arcane thickets of new standards, with the assumption that someone else would spend time on the “boring” work of building professional-quality tools and documentation or cleaning up usability warts. That other 80% of the work never happened and most people who had a choice moved on. As a thought experience, imagine if libxml2 had had even a single dedicated developer focused on tracking standards or making usability improvements, instead of training multiple generations of users that XML was slow and hostile to users. Various XML committees’ travel expenses building standards which were never used likely cost more than that. Not leaving XPath frozen around the turn of the century would have helped in so many places. The other wart I think would have made a surprising difference is the usability disaster around namespaces. So many tool developers forced users to switch between the short namespace:attribute form they used everywhere in the document and the {namespace url}attribute form that resolves to, or forced you to respecify the namespaces on every operation rather than reusing the values the parser had already loaded. Users begrudged that verbosity but they hated it when it meant something silently returned incorrect results because a selector using the document’s own syntax didn’t find the element they could see using those exact values. Absolutely nothing anyone did in the XML world was a better use of time than fixing that would have been since it trained people to think of XML-based tools as a painful, error-prone experience to be avoided — and they did as soon as they could.
• red_admiral 4y ago
  XML is ok when both the reader and writer are machines, but you still want a text-based format (otherwise I'd just use protobuf) or when maybe you occasinally want to edit by hand but not often. I think it's the same reason why, although HTML is a great standard, lots of us like writing in Markdown and having something convert that to HTML, despite all the problems when you try and push Markdown further than it was intended. YAML, as I see it, is trying to be to XML configurations what Markdown is to HTML, with the added bonus of an attempt at a tag/reference system to store object graphs that are not trees. Back in the day of XML-based Spring config files, we had <bean> and <ref bean=...> but as far as I know that's implemented on the Spring layer, it's not a generic property of XML, whereas YAML tries to abstract that into the format itself.
  • thrwawayjan1223 4y ago
    I worked with hand editing XML files in the past, and I didn't really have an issue with simple XML files. I actually prefer XML in some cases. I see your point if you need to edit a complex XML with multiple namespaces mixed together, but a plain XML file can be just as readable as JSON. Some JSON files can be really hard to edit by hand too. At my current workplace I often have to deal with nested JSON files, where a JSON contains values that are also JSON, but encoded and escaped so that it is difficult to edit.
  • bambax 4y ago
    > YAML, as I see it, is trying to be to XML configurations what Markdown is to HTML Yes, that's probably a good analogy. The big difference though is that if some Markdown fails to parse, nothing really bad happens, while a YAML file that fails to parse can bring a whole system down. Also, Markdown is a famously ambiguous format; it trades precision for ease of write, and that's fine, mostly. But in a configuration file, ambiguity is really the opposite of what you want.
• xienze 4y ago
  > I never could understand the hate XML got It's because so many people would see examples of complex _XML-based formats (WSDL, SOAP, etc.)_ and infer that _XML itself_ is complicated. XML is really not that difficult to understand, and I find it quite amusing that the same people who don't bat an eye at writing HTML complain about how baffling XML is. Is writing an XML parser difficult? Yes, very much so. But again, that doesn't make XML itself complicated. And before anyone tries to call out this particular comment, keep in mind that writing a fast, correct, and safe JSON parser is no walk in the park either. Are there many examples of complicated XML-based formats? Yes, but that's just a reflection of the complexity of some particular configuration model, not XML itself.
• singularity2001 4y ago
  XML is preferable for long or heavily nested data structures. For small flat trees the alternatives are preferable
• PurpleRamen 4y ago
  XML is cool and useful, but for humans you need good tooling to handle it well. And it still is very noisy with the all it's boilerplate and what advanced features can bring in. And overall it has a culture of making things complex, and complicated.
• YeGoblynQueenne 4y ago
  >> All that horrible mess, it seems, because people didn't like to have to close tags. If people keep burning their faces off it's not the fault of the flamethrower! If they keep hacking each other's limbs off it's not the fault of the chainsaw! If they keep blowing their houses up it's not the fault of the gas bottles! It's not like we need to accommodate every possible failure mode of the human brain, and make things safe just because the next idiot that comes along is going to cause a catastrophe. It's the idiot's fault that they forget to apply the breaks and take advantage of the failsafes, it's not the responsibility of the system to have the breaks and failsafes where any idiot can find them! I've head that kind of excuse 0 times, outside of software circles. But of course I'm exaggerating because nobody really suffers because of XML other than the people who use it everyday. Like this once junior dev, for example, who was made to create XML by hand by eyballing an Excel document, just because paying a junior dev salary is easier than getting middle management (and clients) to learn to structure an Excel spreadsheet properly. Sometimes, just sometimes, you have to design a tool with the way it will actually be used in the real world in mind. And all the rest of the time? Well, all the rest of the time you have to do it that way, too.
• ppseafield 4y ago
  Just like bad/fragmented YAML libraries now, there were plenty of bad XML libraries and implementations. I didn't think XML was too bad until I had to write a SOAP request where the endpoint would throw an error if the arguments (in their own tags, mind you) weren't in a specific order. The endpoint gave me no hints. Additionally we had to update WSDLs for these services, but the service generating the WSDL used features our server's SOAP library didn't support, so someone had to manually transform the XML and via lengthy trial and error to get it to work.
• MilStdJunkie 4y ago
  Eh, definitely there's some generational round robin going on. And the "amsterdam problem" in YML is just insanity. But you got to admit, XML has some very low level intrinsic problems * Schemas violate underlying XML rules all the time, and due to variance in XML parsers, it gets a pass but only on specific configurations. There's no one Holy XML Parser. Leading whitespace in attributes? Sure, why not?! Whitespace sensitive element order? Ooh yeah, lots of it! But try and feed it to libxml and the whole thing collapses - without error handling, mind you, but that's not XML's fault. * Whitespace agnostic means diffs and merges are element aware, and it's nigh-impossible to estimate the upper compute limit of an element aware diff * There is NO OFFICIAL WHITESPACE SPEC - so if you try and fix it with normalization and lines, it's going to be different everywhere you go. So you're forced to switch on element aware diff / merge in your VCS, which is a pretty big change, and it's one you have to sell other departments on. * XML breaking 1NF, which, aka means that XML can have XML inside of XML infinite recursion when playing data format = which breaks so very very many things . . it's actually going against the whole concept of a data hierarchy, which is built in to XML at a low level. * Sort of riding on that, in order to parse XML you have to eat it element by element, and there's no way to tell when an element is going to end or of it recurses N levels. This makes it computationally expensive. The CAD STEP format has some of this disease - it has to be loaded in its entirety to parse, which can be holy hell with a TB file. * Yeah sure, namespace hell. No one really figured out a way to fix it. S1000D (XML spec) to this day just denies that XML namespaces ever existed, and I can't really fault their WG for doing that. I can fault them for so many other things, but not that.