49 ms·

XML is better than YAML – Hear me out

• nielsbot 3y ago
  XML is well structured, typed and general purpose, but it's a pain for humans to edit. I think the editing pain is one of the main reasons people look for XML alternatives. Personally I wish XML was written a lot more like HAML.
  • d-lisp 3y ago
    XML -> human editable format -> XML I am searching for this, any clue ?
    • kaba0 3y ago
      XML -> a not-piece-of-shit IDE/text editor -> XML
      • d-lisp 3y ago
        This is fine for me, but I cannot force others to do the same, I use emacs, have good eyes and ability to parse XML; now most of people I work with use less than ideal IDEs.
    • emmelaich 3y ago
      Augeas. And other data formats. However, before you start, there were bugs that I found, and Augeas is a bit hard to work with.
    • speed_spread 3y ago
      Checkout KDL
  • matsemann 3y ago
    At least I've never had production errors because of malformed xml. Yaml, though.. A misplaced dash and your list of a single item is suddenly two distinct items instead.
    • nikanj 3y ago
      Malformed xml sneaks through the kitchen window and poisons you in your sleep. Someone puts naively escaped umlauts (ä -> ä ) into the surname field and your entire xml parser borks with unknown entity errors
    • Groxx 3y ago
      While I definitely agree yaml is pointlessly prone to this ("NO" lol), I've had plenty of xml issues. Bad manual attribute encoding, duplicate attributes (pretty easy when there are lots) that vary in behavior depending on your xml reader, using text content instead of attributes, using lists of text nodes as a map that then gets deduplicated inconsistently instead of attributes (to work around needing to manually encode complex or multi-line text into an attribute)... Humans can screw up anything. And more text often allows it to hide for longer.
      • kaba0 3y ago
        But one of them has schema descriptions to prevent these errors as soon as possible.
        • Groxx 3y ago
          Sure, if you define and use it. Same as yaml schemas (they exist!). XML has them sorta built in (basically all (notable) libraries support them), but it's not like it's required or somehow innately protected because of that. It's just a bit easier to adopt.
          • matsemann 3y ago
            But my case was with a yaml validated to a schema. A kube ingress file with a list of rules. My additional dash made it a new entry, in practice allowing everything. With xml it would have been very explicit that I now accidentally had made two rules.
        • throwawaymaths 3y ago
          > But one of them has schema descriptions JSONSchema? It's pretty standardized and well accepted.
  • smarx007 3y ago
    XML is a data format for correct exchange of information between computer systems. Human-friendly editing was never the no 1 goal for its designers. And with good tools like IntelliJ IDEA, I have easier time editing pom.xml configurations than k8s YAML files, to be honest.
    • PaulHoule 3y ago
      Structured editors have been around since the beginning of XML but they have been slow to catch on generally and have never been that popular because people don’t feel in control.
      • NBJack 3y ago
        Ah, kinda. Yes, they existed, but they frequently didn't have many of the more standard features like autocomplete (particularly on both sides of a new tag) and on-the-fly structure parsing that makes much of the painful parts easier to work with. I think we take for granted how good our modern approaches to IDE assistance can be. Ever use the earliest IDE incarnations of Eclipse on a PC still measured in hundreds of Mhz, or when RAM was still in the dozens of MB? That was the world XML found itself in during its inception.
      • fiddlerwoaroof 3y ago
        Electric tags in emacs make it mostly not a problem, and most editors have some equivalent: ‘it’ and ‘at’ motions in vim as well as vim-surround and emmet. But, I agree that this is one of the worst parts of XML
    • marcosdumay 3y ago
      > And with good tools like IntelliJ IDEA Nah, I have an easier time editing XML in a dumb text editor than YAML with the best tooling I've ever found for it. In fact, I have an easier time with any of its competitors people post around than with YAML. What is distressing, because the language has clearly the goal of being easy to write.
  • tremon 3y ago
    I would rather say that XML is untyped (an XML document only contains text of various flavours), and that is why the only concrete example given works in XML but would fail in YAML or JSON: “test this against Go 1.20” > It interprets that as Go 1.2. Well, understand your data format before complaining. YAML, like JSON, understands data types. If you were to write { value: 1.20 } in JSON, it would similarly be interpreted as the numeric value 6/5. The only reason this works "magically" in XML is because XML itself doesn't have data types, it only has text, and the interpretation is left to the user rather than done by the parser.
    • kaba0 3y ago
      XML schema definitely has types.
      • tremon 3y ago
        Nice, I wasn't aware of that. But it doesn't change the argument much: the XML document still only contains text data, and it's the schema validation phase that's responsible for converting the data into the correct format. Validating an XML document is an optional step, and I'm not aware of many tools that use XML as their config that perform full schema validation. To add, the XML specification on decimal data types [0] explicitly says: Precision is not reflected in this value space; the number 2.0 is not distinct from the number 2.00 -- so a decimal data type in an XML document would have the exact same problem as the YAML example in TFA; the only difference is that with XML, the authors of the tool would have to actively shoot themselves in the foot by annotating that element as a decimal type rather than text. [0] https://www.w3.org/TR/xmlschema11-2/#decimal https://www.w3.org/TR/xmlschema11-2/#decimal
        • ImPostingOnHN 3y ago
          > the XML document still only contains text data this is like saying Java is untyped because the source files are just text
          • 3y ago
  • thechao 3y ago
    HAML reminds me of a "whitespace sensitive" ML we used that's 1:1 with XML: node @attr="bob saget" subnode @foo="john" subnode @ham="bar baz" html:h1 p $"this is literal text" It's ok.
    • MathMonkeyMan 3y ago
      Put some parentheses in there and you're good to go :)
      • thechao 3y ago
        It's from a language called BOOT which is parenthesis-free Lisp!
  • raydev 3y ago
    If a majority of programming nerds weren't so averse to building UI to facilitate more complex actions with better guardrails, we'd probably be better off in many ways. Our desire to not standardize anything beyond "human readable ASCII-like" has held us back, imo. Xcode's plist editing ability is a mild improvement over manipulating XML text directly, but could use more obvious shortcuts/hotkeys. Even writing XML in an IDE like IntelliJ isn't great, autocomplete should do a lot more.
    • eviks 3y ago
      Why would you need text-like XML if you get a good tool that converts to a more useful data entry format? Wouldn't you just use more efficient binary encoding for storage/interchange, while converting to something user-UI-friendly?
      • raydev 3y ago
        Yeah, I agree, doesn't necessarily have to be XML. But adding a highly productive UI layer on top of existing standards would be a great start.
• 0xbadcafebee 3y ago
  [flagged]
  • dharmab 3y ago
    I loved YAML until I read the spec, and now I dislike most of YAML beyond the basics and avoid it unless "ease of humans to edit" is a primary goal.
    • politelemon 3y ago
      I think our industry's distraction with config file formats is due to trying to find a reasonable balance between human readable and machine readable. XML was great for machines, YAML is OK for humans, JSON/TOML are somewhere in the middle.
  • coldtea 3y ago
    >Does this dude not understand what a data serialization format is, yet is trying to tell people how to design applications? "Data serialization format" is irrelevant, both XML and YAML are designed for this. It's just that XML was just over-designed (with all the auxilliary specs), and YAML was designed badly from the start, even for mere configuration. If someone thinks the refuted his points or preference because they "understand what a data serialization format is", they are really not understand XML/YAML and the domains they're actually used.
    • 0xbadcafebee 3y ago
      YAML wasn't designed for configuration, and XML wasn't designed for data serialization.
      • coldtea 3y ago
        Both were designed for both. SGML might not have been designed for data serialization (it was designed for document authoring), but the XML standard committees and company representatives were heavily interested in generic data serialization. And YAML was also designed for human readable editing and serialization of configuration among other data serialization needs. "Configuration files" is literally the first use case for it mentioned in the standard's homepage: "Even though its potential is virtually boundless, YAML was specifically created to work well for common use cases such as: configuration files, log files, interprocess messaging, cross-langauge data sharing, object persistence and debugging of complex data structures". But the point is moot. What each language was "designed for" is irrelevant to what it's predominantly used for throughtout the industry. People found a use for them, regardless of whether their designers might or might not foreseen it (they had), and for this use which is what interests people, there are certain issues. If the answer was as easy as "just use a language better designed for that use case and it will solve your issues", they would have done it already. Some have their hands tied because vendors/projects/etc they use, enforce TOML or YAML or XML and have to use them too to work with them. Others find alternatives worses for their use case, but still don't consider the one they use (TOML/YAML/XML/etc) as optimal.
• taeric 3y ago
  XML's curse was that it started with all of the complexity that everyone will eventually add to any possible replacement. Worse still, people felt compelled to use every feature that they could for esoteric reasons. Even worse, the big companies did not actually work well with each other's document definitions. Even ones that were supposed to work well together. That said, you only need to look at the abomination that is an OpenAPI spec that has been annotated to work with AWS to see that the pitfalls are still mostly the same today. (I can also complain about the breaking changes from the old specs.)
  • smarx007 3y ago
    And what happened since to JSON and YAML? JSON schemas to replace XSD, YAML/JSON templating to replace XSLT, jq to replace XPath.
    • pjmlp 3y ago
      Yeah, it keeps being reinvented, badly.
    • nomel 3y ago
      I used XSD templates once. It was really incredible, how useful it was. Nobody understood it, and rewrote it in JSON.
    • lmm 3y ago
      > JSON schemas to replace XSD Mostly unused. > YAML/JSON templating to replace XSLT Generally much more user-friendly. > jq to replace XPath And much better at it, if only due to not shooting yourself in the foot by default with namespaces. The problem with XML isn't that it supports schemas and namespaces. The problem is that it forces everyone to pay the costs of those things up-front, even if they don't use or care about them.
      • smarx007 3y ago
        And because nobody wants to pay the namespace cost upfront, we all end up with vin, vin_no, viNumber, vinNum etc instead of iso3779:vin, for example. Every time we work with more than one API, it's prudent to try aligning the terms used by those APIs.
• datadrivenangel 3y ago
  Fighting words! The author also mentions that JSON is better: "So if you want to write YAML, you can. But it’ll just take that YAML and turn it into JSON behind the scenes. Then they also have a specific Caddy language. So you can give it the Caddy language and then it turns that into JSON behind the scenes. And you can give it an NGINX config and it’ll turn that into JSON behind the scenes. If you have the cycles and time to spare, that’s probably the best solution for most people…"
  • dharmab 3y ago
    At least JSON has a complete and unambiguous specification. If JSON had comments, we wouldn't need YAML 99% of the time.
    • rf15 3y ago
      We actually offer both for configuration files of our software - YAML can be very pleasant to write and read for small datasets or those without much depth, without the overhead of curly brackets and quotation marks on everything. The original problem these formats solve is that people just want a simple nestable key-value structure/format, and both deliver on it - unlike xml. (when do you use an attribute vs a tag and text element?)
      • kaba0 3y ago
        > when do you use an attribute vs a tag and text element When the schema says so — you even get auto-complete for that in any half-decent editor.
        • rf15 3y ago
          I know the history of xml, but just to get back to my original premise: why has a tag (a kind of key in the mind of most readers) multiple "kinds" of values/children in parallel, especially one set that is map-shaped (attributes) while the other is array-shaped (proper children)?
    • 3y ago
• bamboobills 3y ago
  The cognitive load for yaml is infinitely lower than XML or other things that “work” better. The example give about go 1.2 vs 1.20 is a bad one. Go should have gone with 1.02 instead of 1.2. Also you can just convert that into a string. The reason why yaml is great is because I’m tired of learning “better” solutions that only fix the tiny percentage of issues that yaml has, but has a much more tremendous learning curve. XML is overengineered to the point that it’s a confusing mess. Give me yaml any day of the week.
• KingLancelot 3y ago
  [dead]
• haskman 3y ago
  XML semantics, not syntax, are good for configuration too. See https://kdl.dev/ https://kdl.dev/
• sdumi 3y ago
  I'm not sure I understand his example: “I need to configure this server and the server needs to know if this value is true or false.” No, that’s bad. Don’t do that. That’s not a good use for XML. But on the other hand, if you need to mark something bold, then XML is a great choice. I see both cases as being quite equivalent: whether the server needs to know that a value is true/false or that it needs to display something as bold feels quite the same thing, isn't it? Or does he mean that you cannot easily retrieve the value of an arbitrary XML element? Whereas to display a document you just process it sequentially and do not need to 'retrieve' arbitrary data. Is this it?
  • gilcot 3y ago
    It's only a construction to justify author's biases.
    • earthboundkid 3y ago
      Literally every article is that. What’s your point?
      • gilcot 3y ago
        Oh, I was only saying that the article isn't saying that you cannot easily retrieve the value of an arbitrary XML element. It simply putting together selected examples that should deserve YAML and convince us that we must swear XML true. Well, life isn't black and white, but somewhat greyscale. From my experience, none is better and they don't share the same use-cases.
  • TRiG_Ireland 3y ago
    I think I'm with the author on this. The two scenarios are very different. Bold text is probably a span of text within a larger block of text: delimiting it with an opening and closing tag makes sense. A config value is a boolean switch. This makes sense: <element>Some text here. <bold>Some more text here.</bold> And yet further text here.</element> This does not: <value>true</value> That should be: value: true
• ddlsmurf 3y ago
  [flagged]
  • kstrauser 3y ago
    That's uncool. I disagree with the article but there's no need for namecalling.
    • makapuf 3y ago
      I like to set chatgpt to agressive, accusatory mode when I ask it technical questions. Its funnily angry for nothing but helps you anyway (while despising you).
      • kstrauser 3y ago
        Ok, fair enough. Amended to “there’s rarely need for name calling.”
    • ddlsmurf 3y ago
      I do regret somewhat the name calling. But if I were to publish an article with such incredible arrogance and pretension as to judge two of the major techs of the decade, and did so without applying either correctly, I would welcome some name calling. I think the intolerance to this is something of the neurotypical.
  • coldtea 3y ago
    Seldom calling someone "incompetent moron" ranks you higher in the intelligence spectrum by those reading your comment. Not to mention "you're holding it wrong" is seldom a good argument.
  • dang 3y ago
    You can't post like this to HN, and we ban accounts that do, because it's not what this site is for, and destroys what it is for. Would you mind reading the rules at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and sticking to them when posting here? We'd appreciate it.
• kstrauser 3y ago
  Bah. While YAML is far from perfect, it's fine for random config files written by humans. TOML is mostly better, but from its own homepage (https://toml.io/en/ https://toml.io/en/): [servers] [servers.alpha] ip = "10.0.0.1" role = "frontend" [servers.beta] ip = "10.0.0.2" role = "backend" is ugly to my eyes. And I'd rather swallow my own tongue than have to hand-edit XML in the most common case where there's not a dedicated editor for that specific doctype. In fact, I'd echo the linked article's argument back: I don't know of a case where XML is the best option. For human-edited files, pick almost literally anything else. For serialization, JSON handles the common cases and protobufs-and-friends are better when JSON isn't enough. There's not a situation I can imagine where I'd use XML for a greenfield project today.
  • kllrnohj 3y ago
    > For human-edited files, pick almost literally anything else. I'd still take XML over JSON for human-edited files. At least XML supports comments. > For serialization, JSON handles the common cases Counter-point, JSON sucks and is way overused. The types are too fuzzy, the syntax too quirky, and validators/schemas are almost never present. You can bolt that all on, but it wasn't designed for it and it shows. It was designed to be eval()'d, which you should also never do because it's a terrible idea. It's flawed at the foundations.
    • kstrauser 3y ago
      Those are valid points, and while I have a different opinion, I can't say you're wrong about any of it. But I will say that the first time I used a JSON API that had replaced an XML one, I almost wept with relief. Perhaps because JSON is so simple, it pushed APIs toward having simpler (IMO) semantics that were far easier to reason about. Concretely, I'll take an actual REST API (that is, not just JSON-over-HTTP) over the SOAP debacle any day of the week. I know you can serve XML without using SOAP, but to me they're both emblematic of the same mindset. Still, at least neither of them are EDI.
      • deleted 3y ago
        [deleted]
• sodapopcan 3y ago
  Not everyone is writing React, thankyouverymuch. Good points re: XML and its misuse as anything other than a markup language (its in its name, afterall). After using things like HAML and whatnot for a few years I went back to plain HTML. I like it much better. YAML, meh, I choose to use it in Hugo because that's what I'm used to and I'd rather not learn a new config language until I'm forced to. I prefer config to just be in the language I'm working in, though many people disagree for various reasons but, you know, like, whatever, man.
• bastardoperator 3y ago
  I don't care. I use yaml because a human can typically parse it and the files are always smaller.
  • Smaug123 3y ago
    As I am fond of saying, there's a common misquotation that runs "YAML is easy for humans to read". The full quote is "YAML is easy for humans to read wrongly".
    • bastardoperator 3y ago
      If humans could get it right the first time, we'd all be unemployed.
      • Smaug123 3y ago
        Even I'm not so cynical as to claim that a tool is good because it's hard to use correctly so it makes work for us when we inevitably get it wrong!
  • tremon 3y ago
    This. There is no use writing "X is better than Y" without specifying what metric(s) you're using. If it's about human legibility or editability, YAML is better than XML. On the other hand, I would never use YAML as a machine-to-machine data interchange format; for those, JSON or XML are superior. I also had to laugh at this statement: the YAML specification has all these features that nobody ever uses, because they’re really confusing, and hard, and you can include documents inside of other documents, with references and stuff That's a pretty funky argument to use in favour of XML.
  • MrPatan 3y ago
    I can't parse it.
  • postalrat 3y ago
    Best parsed with a ruler on the screen.
• cies 3y ago
  YAML is more like JSON or TOML. XML is a whole other beast. So it really depends on your usecase. Do you need to be able to import several independently developed vocab and use them, possibly namespaced, in a single document... Seriously, go XML.
  • verdverm 3y ago
    CUE does not integrate with XML yet because of these beastly features, in particular how to handle attributes on an object when it also has nested content. It's basically the same problem of how you would transform XML into yaml or json, though there are more options in CUE
• shaftway 3y ago
  Personally I use textprotos for configuration whenever I can. - Syntax for the configuration is straightforward. - Syntax for the definition is straightforward. - It supports comments (end of line and full line). - It's not NP complete and there is no weird parser meta-language or includes. - There are parsers for any major language I've used in the last decade. - It gives me a strongly typed definition so I don't have to infer or parse values. - It's easy to verify the validity during lint tests by using protoc to encode to a binary proto. It'd be nice if it supported unicode a bit better, but it's configuration, so that's not a common concern.
  • shaftway 3y ago
    Textproto version of the TOML homepage example that kstrauser's called out: servers { alpha { ip: "10.0.0.1" role: "frontend" } beta { ip: "10.0.0.2" role: "backend" } }
    • kstrauser 3y ago
      Ooh, shiny! I like that. It looks a lot like HCL, but with the lessons learned from making protobufs.
    • em-bee 3y ago
      looks like json without commas. i like that. but i don't like that the outer keywords don't have a colon while the inner ones do. it feels inconsistent.
  • jiehong 3y ago
    Sadly, list of elements in textproto, being repeated items, appear repeated, which isn’t great.
    • tantalor 3y ago
      Can you expand on that a little, what do you mean exactly?
• PaulHoule 3y ago
  I think a lot of YAML hate comes from the systems that use YAML (all those things that configure virtual machines, containers, cloud assets, etc.) that have bad data models to begin with and are part of bad architectures. (e.g. Hashicorp seems to come out with a new product every week to fix the problems with their old products)
  • geodel 3y ago
    Well that seems to be The tools we make makes us type of situation.
  • politelemon 3y ago
    While we're on spicy takes, k8s use of Yaml is an abomination and should have been vetoed early on. The data model they're using is too hierarchical and might have been better off in XML or Json
    • PaulHoule 3y ago
      That's exactly what I am talking about. K8S is a disaster. It makes Parallel Sysplex for IBM Z look positively simple in comparison.
      • jdougan 3y ago
        TIL about Parallel Sysplex. What a great name.
    • dpkirchner 3y ago
      I think helm's use of YAML makes it worse because it uses a text template library to manipulate structured data, and thus requires annoying stuff like {{indent}} and {{nindent}} when you want to insert objects. To me, whenever I find myself using one of these indent functions I'm reminded of the well known pitfalls of using regex to parse HTML. I don't know what I'd prefer, exactly. Probably JSON, or better yet JSON5.
      • 3y ago
• pjmlp 3y ago
  1000x yes! YAML spaghetti is so much worse than dealing with XML tags, no tooling, no schema validation,...
• pxeger1 3y ago
  > Also the YAML specification has all these features that nobody ever uses, because they’re really confusing, and hard, and you can include documents inside of other documents, with references and stuff XML also has these?!? In fact I'd guess YAML was developed to mirror the feature set of XML while having nicer syntax for humans.
• dragonwriter 3y ago
  > Well, when you say in your test file: > “test this against Go 1.20” > It interprets that as Go 1.2. Without actual YAML (“test this against Go 1.20” YAML would interpret as the string “test this against Go 1.20”), its hard to know the actual complaint here, but it sounds like there was a YAML file with something like: testTarget: - language: Go - version: 1.20 Where the tool interpreting expected a version string in “version”, but also accepted a number and implicitly converted the number to a version string. This is not a YAML problem, this is a “code that accepts and implicitly converts invalid data problem”. Its true that a schema and validating parser would help with this, and YAML doesn’t have a broadly supported standard schema language, but I bet the real problem here was that the underlying tool was written in JavaScript, as its the main popular language where even the most naive attempt to parse what you expect to be a string value would not fail if the value was actually a number.
  • SahAssar 3y ago
    YAML is far to helpful to convert bare strings to what it thinks is right (like 1.20 to 1.2 or no to false). It could be helped by having data validation, but the fundamental issue is that YAML does not make it clear to either human or machine what is meant or expressed. The issue is not isolated to JS either, the same could have happened in python, php, or any other untyped language.
    • dragonwriter 3y ago
      > YAML is far to helpful to convert bare strings to what it thinks is right (like 1.20 to 1.2 or no to false Versions of the YAML standard from the last 14 years don't do the later, and supporting numbers as a basic data type is, honestly, a weird thing to harp on as “too far”. > The issue is not isolated to JS either, the same could have happened in python, php, or any other untyped language. Indexing an associative array of runtimes that is keyed by a string, or doing almost anything else that expects a string, when you get a number instead, will fail with an error in most dynamically typed languages including Python and PHP; much fewer string-expcting operating operations (and particularly not object indexing) will fail in JS with a number.
  • 3y ago
• gmuslera 3y ago
  "Better" is a loaded word. Behind it there is a lot of criteria, priorities, ways to measure, subjetivity and more. Your context for that word may be different than mine.
• shashashasha___ 3y ago
  They are both trash!!! I do agree that TOML is a better option. Easy to write and easy to read.
• MilStdJunkie 3y ago
  It's an abuse of Ycombinator servers that I can't paste a Billion Laughs statement that just fills up your parser with NONONONONONONONO for the next sixtillion eternities. Because NONONONONONO . . OK seriously. Seriously. These people all chillin' here in the future and talking about how great XML is need to jump in my DeLorean back to 2002. Or maybe try using XML for a few years. Or decades. * Schemas break XML *all the time*[1], * "XML-aware" diff/merge[4], * No Such Thing As Line Breaks[2], * Sneaky proprietary entities[3], * NAMESPACES, * "1NF? Is that a sex thing?", * Computability[4], * FRICKIN CHARSETS, * asemantic but pretends to have semantics, * Hierarchy Fetishism And so so so much more. The combined effect of this is that it reduces the volume of the tool ecosystem for a given XML spec. Don't believe me? Run the metrics on gitlab/github/npm/pip/DaSEA[5]. So the tool ecosystem is - very often - only as big as a singular project. It's one of the reasons there's so many XML editor vendors. In S1000D, it's pretty common to have a special vendor for each project. XML completely nukes, by its essential nature, any possibility of using standard tools. There is an entire category of emergent technology - Lightweight Markup Languages - that were invented, by individuals, working for free, for no other reason than to get out of XML. Using XML at scale is something that should never happen, for any reason, ever. It's this horrifying perfect storm of non-technical academics steering a crew of malcontents still angry at how GML went. Ol' Linus was a bit of a butthole, but he was right on the money when it came to XML. ALL of the problems YML has that are mentioned - they can ALL be found in XML, but they're magnified times fifty bazillion because of the inherent lack of support. [1] Leading whitespace in attributes? HOW CHARMING. Yeah, that's in a schema, a very popular one. So each schema is its own language, and both DITA and S1000D allow for virtually any level of customization on top of that, and on top of THAT, in S1000D, you have to contend with each of the Issues. Seriously, it's a flashback to the pre-ATA100/JASC 1930s "shop manual" systems. [2] No such thing as "normalized" when it comes to XML whitespace, which means no lines, no tabs, no spaces. Everything is elements. Oh, ha ha, unless there's dual-mode DTD/XSD validation . . which should REALLY have its own bullet. Do you realize, in any way, how incredibly radioactive external entities in a internet-facing parser are? [3] REVBARS! Oh, and FRICKIN CGMs. Good luck processing those, because they were golden tickets handed out to ISO-favored software vendors. [4] Infinite arbitrary nesting combined with whitespace agnostic means it's REALLY hard to make any sort of compute optimization unless you load the WHOLE thing into memory. An xml-aware git repository has performance several orders of magnitude worse than a normal one, and if used in quantity with goofball schemas, you can actually choke a Bitbucket CLI. [5] https://dasea-project.github.io/DASEA/ https://dasea-project.github.io/DASEA/
• mcdonje 3y ago
  I use YAML for config files, and I think that's what most people use it for. So, I thought this was going to be an argument for using XML for config files, but it's just bashing YAML. YAML is easy to read like TOML or INI, has comments unlike JSON, and has dictionaries unlike TOML or INI. It's not bad. It's not YAML's fault they didn't quote their numerical strings.
  • Tao3300 3y ago
    I for one appreciated the observation that if you're using XML for something that isn't a document, you're probably doing it wrong. I recall (perhaps inaccurately) seeing that notion somewhere in http://www.catb.org/~esr/writings/taoup/ http://www.catb.org/~esr/writings/taoup/ and it was at once a shock yet seemed so obvious. Might have been in something else esr wrote, but I've always considered that one to be his masterpiece.
  • throwawaaarrgh 3y ago
    Yaml is not a configuration format. It is a data serialization format.
    • c-cube 3y ago
      Why would anyone use it for serialization, when json exists? Yaml is harder to parse and the implementations have a history of security issues because it's so complicated. If you're not writing it by hand why bother at all?
      • throwawaaarrgh 3y ago
        You haven't read the spec, I take it. Read the spec, compare it to JSON. It should become apparent what features Yaml has that Json does not.
    • kelnos 3y ago
      Regardless of what it was meant for, it's a worse serialization format than it is a configuration format, despite its warts.
• mharig 3y ago
  For config files and the like, StrictYAML is the way to go. https://hitchdev.com/strictyaml/why-not/toml/ https://hitchdev.com/strictyaml/why-not/toml/
  • AndyKluger 3y ago
    Unfortunately that's not a spec, only a (language-specific) tool. For a similar spec that offers no types outside of string, list, and dict, there's NestedText.
• daft_pink 3y ago
  I find YAML to suck having used it in the serverless framework and many of my terrible bugs came from it. However, json is better than xml I think as a compromise between the two.
• esbeeb 3y ago
  I, for one, am displeased with .yaml. I recently had a major footgun incident where a Debian VPS was rendered completely unbootable because of Ubuntu netplan's highly-annoying use of YAML (where I had done the slightest misconfiguration, and to my eye it looked perfect, and my changes successfully passed the parser of "netplan try"). Yes, that's right - the server needed to be rebooted in rescue mode; it wasn't just merely stranded with no working network interfaces, where the web-based serial console would have been enough to undo the footgun gunshot. Nightmare! The solution was to uninstall netplan.io Debian package where it didn't belong - get that YAML out of there. My hosting provider, OVH, figured it would be a good idea to shoehorn netplan - with its accursed YAML - into Debian for Network configuration. Bad move. +1 for TOML. I love it's usage in innernet config files to set up new clients with a single generated "invitation" file.
  • ArchOversight 3y ago
    It's not your hosting provider that did that, it's the Debian project.
    • rubatuga 3y ago
      Are you sure? Debian from what I understand uses standard /etc/network/interfaces
    • mkj 3y ago
      Debian doesn't usually use netplan? It's written by Canonical for Ubuntu.
      • vbernat 3y ago
        This is now part of the cloud images for Debian.
        • esbeeb 3y ago
          And then OVH makes you hand-configure your IPv6 address, with netmask and IPv6 gateway - no DHCP6 for their VPS servers. Then they put the footgun in your hand by not mentioning the double-quotes requirements which YAML has for IPv6-with-netmask.
• pharmakom 3y ago
  Yaml is total garbage. I’m not sure what is best, but it ain’t yaml. The Norway problem is unforgivable.
  • yboris 3y ago
    "The Norway Problem" - had to look it up: https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/ Norway abbreviates to "NO" which YAML parses as "false"
    • Dylan16807 3y ago
      They fixed it a long time ago... except half the implementations haven't updated.
      • zaps 3y ago
        Correct. It’s not YAML’s fault that the parsers haven’t caught up to its fixes.
        • eviks 3y ago
          but it is YAML's fault that it introduced this silly mistake in the first place
        • miffy900 3y ago
          No it's YAML's fault - the fact that type coercion was once part of the serialization spec and not part of an adjacent schema spec is a tragic mistake. Now there's a bunch of outdated parsers that exhibit the issue and some that have it fixed. Meaning even more inconsistency and frustration. In an ideal world, YAML just shouldn't exist.
  • mianos 3y ago
    NO it's not, or False it's not or Not "NO". Ok you win. What a joke of a configuration language.
  • 3y ago
• atum47 3y ago
  YAML is the worst
• crest 3y ago
  Why can't more software just use libucl and let users decide how human readable they like their configurations?
• raytopia 3y ago
  That looks like an annoying problem. Really need a decimal type for that. As an aside has anyone tried making Python object notation? For instance you'd get tuples, sets, complex, hex, etc. along with dicts, lists, and all the other stuff json has. I know you can use literal eval but it has some security issues json doesn't have.
  • tpmoney 3y ago
    Realistically, a decimal type with defined precision is just a coverup for the real problem which is that version numbers aren't decimal numbers. If "1.2" < "1.19" < "1.20" that's not a decimal number and treating or storing it like one is a problem. I've seen this time and time again in software projects where someone treats the version number as a decimal, which works great right up until they have more than 9 minor versions, someone adds a bugfix version or someone adds a beta/alpha suffix. Then a whole bunch of stuff breaks that was making bad assumptions.
    • raytopia 3y ago
      That's a very good point. I guess we need a version type? Or something.
  • ceras 3y ago
    Starlark, used in Bazel, is in that vein, though goes a bit further by supporting functions (with many restrictions): https://github.com/bazelbuild/starlark/tree/master https://github.com/bazelbuild/starlark/tree/master
• qlkjwenf 3y ago
  YAML creators are very big fans of overengineering.
  • mardifoufs 3y ago
    Not sure if that's a good argument in a comparison with XML. Something about pots calling the kettle black...
• rubatuga 3y ago
  For those wanting human readable and editable configuration files, NestedText might be a solution. It only supports strings, but conversions can be done during import anyway. https://nestedtext.org/en/latest/ https://nestedtext.org/en/latest/
  • FireInsight 3y ago
    NestedText already is the way I use YAML; everything is intepreted as a string. I have some trust in my YAML parser to not mangle most strings. I could use NestedText, but users would be unfamiliar with it, and IIRC the only parsers are in Python. But then I could use StrictYaml too https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml
• skywhopper 3y ago
  YAML bashing is sooo tiresome. Yes it has quirks and tries to do too much. And yet JSON and TOML have their own broken idiosyncrasies as well. But in the end they are all trivially interchangeable with each other for 99% of their use cases. But XML is not even a comparable standard. XML addresses an entirely different problem space. It cannot be directly mapped into baseline common data structures in most other languages like JSON/YAML/TOML. Saying XML is “better” than YAML requires defining your problem space. Otherwise it just looks like you don’t really understand the difference between the two.
• dkackman11 3y ago
  Gonna date myself but, for ~80% of configuration needs good old INI never let me down. Named sections of name value pairs with string and number data types (maybe bools too. do not recall). et voilà!
  • issafram 3y ago
    [flagged]
  • geerlingguy 3y ago
    Honestly if the config layout fits in ini, there's no reason not to use it. YAML is great for human-readable config, and there are footguns. XML is terrible for human-readable config. JSON is not great for human-readable config. TOML is okay for human-readable config. The problem is there's no clean way to abstract strings, bools, lists, objects, trees, etc. into a human-readable configuration syntax that does not have a footgun.
    • AndyKluger 3y ago
      > The problem is there's no clean way to abstract strings, bools, lists, objects, trees, etc. into a human-readable configuration syntax that does not have a footgun. My favorite take on this by far is that any types beyond string, list, and dict don't belong in the format at all, and should be left to the ingesting code. I started on the path thanks to StrictYAML and found a home with NestedText.
  • kelnos 3y ago
    INI is great for some flatter types of configuration (and I still use it too), but once you need a little bit of nesting, or lists, INI starts to get cumbersome.
• Devasta 3y ago
  Not only is XML better than YAML, it also better than JSON.
• musicale 3y ago
  YAML has been OK for me, but I think it could use some schema and type standardization. I still like GNUstep's extended version of NeXT property lists.[1] XML and JSON seemed like a step backward on macOS at least. https://en.wikipedia.org/wiki/Property_list https://en.wikipedia.org/wiki/Property_list
  • throwawaaarrgh 3y ago
    Yaml has a schema and standardized strong types. You can even define custom types. You can also write your own validator.
    • musicale 3y ago
      > You can even define custom types. You can also write your own validator I think the problem may be that yaml systems I've used haven't done this well.
• MenhirMike 3y ago
  No offense to the creator of YAML, but: The fact that it became one of the de-facto standards for cloud tooling is an absolutely damning statement about the state of the industry. I get that XML is about as sexy as mainframes, and that a lot of folks here probably have PTSD from working with Java/Spring web apps, but YAML is about the worst of all worlds. Though I think the real problem is that real-world configuration files are way too complicated for a simple/dumb/logic-less representation like a .ini/.conf file, so someone thinks to add some logic to is - which is just config-as-code. In a terrible programming language. If you want config-as-code (and you want to!), just do it properly and use a proper programming language for it. Don't care which one, be it JavaScript, Python, Go, PDP-11 Assembly, or Rust. But please stop with these half-measure DSLs that just don't cut it.
  • jandrese 3y ago
    Also, config files that are also programs are a classic security vulnerability. Fun!
    • richbell 3y ago
      The author of SnakeYaml argued vehemently that a library executing untrusted code by default was a feature that people wanted. https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-202...
      • lodovic 3y ago
        wow, what a read. I'm now convinced to immediately remove that library if I ever come across it.
      • ludwik 3y ago
        Wow, this is truly terrifying. It reads as if Donald Trump was the maintainer of a popular library. "Low quality tooling! Sad!!!". He claims with a straight face that every software using his library only loads YAMLs from sources 100% trusted to execute code. He is given example after example to the contrary, which he ignores instead opting to constantly blame "low quality tooling" for generating "false reports" about his perfect software. People can be really weird sometimes.
• stevefan1999 3y ago
  I don't like YAML simply because it is indented like Python, and I don't like Python.
• talent_deprived 3y ago
  KISS XML is the best, so glad to see people like the author coming around to it. JSON is fine for JS (since JS isn't likely to ever be gone from our lives) but YAMl, as the author said, never has a case the makes it worth dealing with. Yet, YAML is everywhere. I even use it in my personal Spring Boot projects it's become so ingrained.
• mrbonner 3y ago
  I do think XML gets the bad rap from its abusive usage in RPC/services. Using XML in those cases resulted in bloat. But, from a configuration language or markup language point of view, I can hardly find something that offer: schema for validation, IDE with auto-completion (I used to use Eclipse and it filled out the enum, attributes very well), comments, and raw string data (use the CDATA tag) gracefully like XML. Go on, prove me wrong.
  • imoverclocked 3y ago
    For something like rpc where data is automatically encoded/decoded then there are definitely better alternatives if you don’t need string representation of the entire blob. Eg: protobuf has a schema and code generation for most languages that can then work with whatever editor you use to write code. I think editing xml is just as bad as editing anything else and is only made better by having some kind of plugin which understands xml + a specific schema.
  • Mikhail_Edoshin 3y ago
    AFAIK Vim can do simple XML auto-fill given a DTD. (Never tried it myself though.)
• pyuser583 3y ago
  XML has way too many features and edge cases.
  • tormeh 3y ago
    Wait until you read the YAML spec…
    • marcosdumay 3y ago
      I guarantee you, XML has more of them. If you keep your comparison between those two, you will lose every time.
• eduction 3y ago
  EDN! The extensibility of XML with the concision of JSON (or even more concise if you use keywords for your hashmap keys). https://github.com/edn-format/edn https://github.com/edn-format/edn
  • deleted 3y ago
    [deleted]
  • mkl 3y ago
    And a lot more confusion than either? If I'm understanding correctly, this is a valid map: {:a 1 2 :bar [1 2 3] :baz}
    • dekelpilli 3y ago
      It is, as it should be. I'm struggling to format it nicely here in HN, but I believe that the formatting show here [0] is more readable than JSON or YAML. It gives you type flexibility (instead of JSON's string-only keys). What's the source of your confusion here? [0] https://github.com/bbatsov/clojure-style-guide#opt-commas-in-map-literals https://github.com/bbatsov/clojure-style-guide#opt-commas-in...
      • mkl 3y ago
        The confusion is that the order of the key and value can be reversed, and commas are optional, so there's no way to tell at a glance what e.g. the value associated with:bar is.
        • eduction 3y ago
          >the order of the key and value can be reversed This is the case with any hash-map in any language, modulo some of them making certain keys illegal. But "string":"string" can be reversed in pretty much any language's hash-map. >here's no way to tell at a glance what e.g. the value associated with:bar is. You've certainly constructed and formatted a hash-map that is a little tricky to understand, but 1> this combination of key and value types is going to be pretty rare in the wild and 2> to the extent it exists, people would format it to be easier to parse, either by adding commas or newlines.
• ekvintroj 3y ago
  I think syntax highlighting and autocompletes really help with readability. But when the syntax is implicit, I don't know what to think.
• booleanbetrayal 3y ago
  How do you DRY up an XML file like you can with YAML anchors?
• Cloudef 3y ago
  I don't really know why Yaml got so popular. It has tons of footguns, and it's being misused as custom "programming language" making all the yaml soup unreadable.
  • krapp 3y ago
    It got popular because it uses significant whitespace, and a whole generation of developers who grew up on Python refused to touch anything that didn't.
    • WkndTriathlete 3y ago
      It got popular because it's far easier to read and edit hierarchical and array data in YAML than it is in XML (or JSON). Most of the time I don't need a format with support for some esoteric charset or namespaces or any of the other baggage that comes with XML, I just need a quick way to exchange regular, structured information, possibly with comments, in UTF-8, that is easy to read and write. Show me a better format that doesn't make my eyes bleed from the angle brackets (or the curly braces from JSON) that is commonly supported across lots of programming environments and I'll happily switch to it.
  • throwawaaarrgh 3y ago
    Yaml does not have footguns. It has dumb humans who use it as a configuration format, when it is a data serialization format. Using a car engine as a pizza oven would also result in problems if you tried to cook a pie with it. But having a toxic half cooked pizza doesn't mean the engine has footguns. The engine works fine if you use it to drive to a pizza place to pick up a pizza.
    • Cloudef 3y ago
      >when it is a data serialization format. How? It's even worse as a serialization format. Why would you want to serialize into human readable blob anyways? https://github.com/cblp/yaml-sucks https://github.com/cblp/yaml-sucks
• ldhough 3y ago
  Wish edn was more popular outside the Clojure world, it is so much better than the alternatives imo.
• coolgoose 3y ago
  Imho, people should always remember that the only good "type" in yaml is to quote everything.
  • throwawaaarrgh 3y ago
    You're using it wrong.
• bradgessler 3y ago
  Caml
• imoverclocked 3y ago
  I wrote a dns management system some time ago and used xml to describe the base data. I’m hard pressed to know of a better format where you can hand-edit, easily diff, have schema validation of data, and reliably transform the data into other formats (in this case bind, isc dhcp, and documentation with graphviz+html) OTOH, I’ve seen xml schemas that would make a rattlesnake cry.
  • nextaccountic 3y ago
    json with json schema https://json-schema.org/ https://json-schema.org/
    • imoverclocked 3y ago
      Json diffs are horrible.
• kortex 3y ago
  XML is overwrought, YAML is a foot-bazooka, JSON lacks comments, TOML gets unwieldy with more than a few levels of nesting, EDN is neat but kind of obscure... Maybe we need a new configuration format... ducks Actually I think something in the space of JSON5, Jsonnet, GCL, HCL, CUE, etc, will be the one to win out in the long run. JSON-but-fix-most-of-the-warts. Then there's things which almost sit between fully declarative and turing-complete. Maybe Dhall, if it picks up a few more language implementations. Or CEL. https://github.com/google/cel-spec https://github.com/google/cel-spec
  • throwawaaarrgh 3y ago
    Yaml and Json are not configuration formats. They are data serialization formats. Xml is a markup language.
  • hmry 3y ago
    +1 for EDN. In terms of new formats, I'm quite fond of RON, it hits a similar sweetspot in flexibility. JSON5 is nice too, mostly because it's popular. IMO Jsonnet, CUE, etc are just in a different category of complexity since they include code and require a full-blown interpreter to read.
  • crimsonpowder 3y ago
    XML's biggest problem is perfectly demonstrated in Apple's plist files. There's no real way to do lists so 15 ways have been invented ad-hoc.
  • Too 3y ago
    Using Terraform/HCL as a pre-processor to generate any of the other formats seems like the best now. It is - No footguns (compared to the alternatives) - Basic text-templating - Can do structural manipulations of data. As opposed to many other config-generators that only do string-interpolation of text. Helm and j2.... kill me please, who ever thought this was a good idea - Basic looping, transformations and function calls. Without falling into the full imperative programming language trap. Configuration is still deterministic and directed. - Supports loading data from other sources - Supports comments
• pezezin 3y ago
  Whenever this kind of arguments come up, I am sad that RON (https://github.com/ron-rs/ron https://github.com/ron-rs/ron) is not better known. To me it feels like a cleaner and better JSON. In any case, my little experience with it had made me hate YAML. Generally speaking, I have come to dislike any language with significant whitespace other than Haskell.
  • throwawaaarrgh 3y ago
    Yaml is not a language. It is a data serialization format.
    • kelnos 3y ago
      You can stop posting this over and over. We get it, you're adamant about using it only as a data serialization format.
    • pezezin 3y ago
      It has a grammar and a syntax, so it is not a programming language, but it is a formal language.
• imbnwa 3y ago
  KDL[0]? [0]https://kdl.dev/ https://kdl.dev/
• deleted 3y ago
  [deleted]
• kelnos 3y ago
  I recently started a new small software project, and, out of habit, reached for YAML as the configuration file format. This article reminded me of the ways that I do really dislike YAML, though it didn't mention what is to me a more annoying parsing oddity: country: no YAML will interpret that "no" as a boolean "false". Which... c'mon. So I started thinking... maybe I should use something else instead. TOML? Nah, my config file requires around 4 levels of nesting, and nesting in TOML isn't great, at least when done the more idiomatic way. JSON? No, I want comments, and I hate having to double-quote all the keys. XML? No, way too verbose; the author of the article goes into more detail why XML is bad for a configuration language. HOCON? I've used it in some Scala projects, but I'm a little worried it's not mainstream enough and users might be confused at the syntax (or annoyed that they need to learn a new format, even if it's simple). CUE? I'd never heard of it before it was mentioned in this article. "Validate, define, and use dynamic and text-based data" -- um, that sounds scary. I don't want a language, I want static, declarative configuration. Sigh. I guess I'll stick with YAML for now.
  • throwawaaarrgh 3y ago
    Do. Not. Write. Yaml. By. Hand. It is a serialization format. That means it is meant to be written to by a program, not a human. You will screw it up, a number of ways, if you write it by hand. It is only designed to be human-readable, not writeable. It is not a configuration format, it is a data serialization format. I feel like we need that in giant bold red letters at the top of yaml.org. Nobody gets it.
    • deleted 3y ago
      [deleted]
    • kelnos 3y ago
      And yet you haven't presented alternatives. It's easy to dunk on something, harder to be constructive, I guess. You may disagree with my reasons for not liking the others I mentioned, but that's just your opinion, and when I'm writing my own software, my opinion holds more weight.
• fzeindl 3y ago
  Just dropping the tip here: xmlstarlet is a great tool if you want to query xml on the commandline using xpath or do some xslt transformations. Similar to jq's utility for processing json.
  • pimlottc 3y ago
    What’s great about xmlstarlet is you can do a quick and dirty ad-hoc transformation on the command line, and when that starts getting too elaborate, you can generate the equivalent XSLT and use it anywhere.
• darthrupert 3y ago
  Everything's better than YAML.
• hnax 3y ago
  It's a bit rich having the whole case hung up to the fact that YAML interprets numbers as numbers and not as strings. What when your go version moves to 1.20.1 ...? You'll have to stringify it. Iow version members should always be strings.
• laech 3y ago
  Years ago when parsing XML in Java, to my surprise at the time, the parser by default would try to resolve external DTDs while parsing, ouch, what a way to let someone DDoS your system. Unfortunately YAML was even worse in that regard, as it allowed arbitrary code execution as seen in recent CVEs...
• gorgoiler 3y ago
  In terms of being able to extend the worlds most common markup language: it’s 2023 and you can make a <cat> element in your HTML and style it with cat{color:brown;} We got there. We got the extensible markup tooling we needed. Gosh, it took a long time though.
• jstop107 3y ago
  There's not much evidence in this article. Its always worked well for me and being more readable saves a lot of time and helps me better visualize and comprehend what I'm working on. If there are more glitches like the version issue the writer ran into I have never noticed that issue or others significantly impact me. Maybe its just my infrastructure engineering use case hasn't run in to them but I need more evidence before I'll grab the pitchforks with you.
• vram22 3y ago
  Not 100% sure but I think YAML became popular due to its use by Ruby / Rails.
• emodendroket 3y ago
  OK, I heard him out and I didn't really hear much of an argument so much as handwaving about how YAML is bad. He's provided exactly one edge case where it didn't do what he expected because (I guess, if I understood the context) he used a number type where a string would have worked better. Which serialization format is immune to those issues?
  • kelnos 3y ago
    Except he didn't use a number type, or at least didn't think he was: YAML allows you to write strings without quoting them, and has heuristics to decide if an unquoted thing is a string or something else. For another example: YAML 1.1 would treat "yes and "no" as boolean true and false. I've heard this called the "Norway Problem": country: no Whoops. I had never actually considered the issue in the article, and I wonder if I've ever made a similar mistake with numbers and didn't realize it. Honestly I think I would be fine with YAML if strings were required to be quoted. Yes, that would make things a tiny bit more verbose, but it would remove a big footgun.
    • emodendroket 3y ago
      Yeah that probably would have been better. Can’t really change it now though. I think everyone who uses a lot of YAML is aware of this issue and would know exactly what happened immediately; it’s up there with Java string compares by reference in terms of “everyone using the tech knows this pitfall.”
• nologic01 3y ago
  The main complain about XML (in the config file context) seems to be the difficulty of editing it "by hand". If think about it, thats not a problem of the format but of the editors people typically use. Simple text editors used in a command line use a line paradigm rather than a tree paradigm. Thats not well suited and its not the fault of the format. Given that trees is about as fundamemtal as it gets as a data structure maybe what is really needed to end these format wars is not a new format but a new editor or editor plugin.
  • eviks 3y ago
    requiring closing tags to repeat tag name is one of the issues and is not tree related, but is the fault of the format
• riffic 3y ago
  to heck it is
• pkulak 3y ago
  Wow, Cue looks kinda awesome. How come this is the first I’m hearing of it?
  • BiteCode_dev 3y ago
    It's mentionned every month on HN. But for now there is only a go implementation. Someone will eventually implement it in rust, and then all languages may adopt it.
• theanonymousone 3y ago
  This is one of the few HN discussions where I feel a little bit qualified to give an opinion :) Two years ago I started a small data quality checker software where users could define their alerts, frequencies,.. all in config files instead of modifying code. I initially chose JSON as config format, but then realised comments are necessary to guide users in defining alerts. I moved to YAML, but after some "indentation incidents" started using HOCON conf [0] and never looked back. I don't see any reason for choosing YAML over one of JSON or HOCON, except being forced to because of some dependency. Features such as inheritance and text block support which were essential for me are nicely supported in HOCON. [0] https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md
  • shahargl 3y ago
    hey! would be cool to chat about what you've build. we are currently building Keep (https://github.com/keephq/keep https://github.com/keephq/keep) where you can define alerts as YAML's. would be cool to learn from you.
    • theanonymousone 3y ago
      It was an internal tool for my employer, although I would have loved to make it open source. Anyways sure. We can talk.
• edem 3y ago
  I don't need to hear you out, xml *is* better than yaml. Yaml is just a random descriptor that can be ruined by a typo. xml has xslt and xsl, and what have you. It just happens to have a shape that went out of favor because of monstrosities like ESBs and Spring and people have PTSD. I can easily validate and transform my XML just by writing more XML which is awesome. This is why I don't use yaml if I can help it. If I want some descriptor JSON is still better since I can validate it with JSON Schema, or whatever validator I choose out of many. Yaml on most platforms is barely supported.
• ajanuary 3y ago
  The problem with YAML as a configuration format can be boiled down to two things: 1) significant whitespace; that one is obviously subjective 2) encoding types in the document When I’m reading the `maxItems` property from it, I know it’s an integer. Why do I need the document author to also tell me it’s an integer? For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point. `config.getInt("maxItems")`. Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted. By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues.
  • dragonwriter 3y ago
    > When I’m reading the `maxItems` property from it, I know it’s an integer. Why do I need the document author to also tell me it’s an integer? Because this allows well-designed client libraries to detect conflicts between the document-author intent and programmer intent, enabling mismatches to fail as errors rather than being read other-than-as-intended. > For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point. Yes and a client in such a language should fail (or have a mode in which it fails) if the value is not actually, as read in YAML semantics, a type compatible with what you are asking for. > Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted. Schemas are for validation, not interpretation. If you use them for interpretation, then you get JavaScript-esque weak typing, and the errors that come with it (basically, magnifying the kind of YAML 1.1 problems that YAML 1.2 tamped down.) > By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues. What you propose is an explosion of Norway-problem-style potential for values to be interpret other than as intended by the document author, not a mitigation.
• jillesvangurp 3y ago
  We use Kotlin to generate the yaml for our github actions: https://github.com/typesafegithub/github-workflows-kt https://github.com/typesafegithub/github-workflows-kt Nothing like a good old type safe compiled language to cut down on the verbosity, copy paste usage, silly syntax errors, weird undocumented you just have to know the magical incantations, etc. Kotlin or similar languages are the way to go. Much safer, more compact, easier to cut down on the copy paste reuse (which is just miserable drudgery), easy to introduce some sane abstractions where that makes sense. You get auto completion. And if it compiles, it's likely to just work. People keep on moving around the deck chairs on the proverbial Titanic when it comes to configuration languages. Substituting yaml for json or toml just moves the problems. And substituting those with XML just introduces other issues and only marginally improves things. Well formed xml is nice. But so is well formed json. Schemas help, if the urls don't 404 and you have tools that can actually do something with them. Which, as it turns out is mostly not a thing in practice. And without that, it's just repetitive bloat. XML with schemas becomes very hard to read quickly. There's a reason, people started ignoring XML once json became popular: json does most of the essential stuff well enough that XML just isn't worth the effort. And if you have something where you'd actually need the complexity of XML, it's likely to be some really ugly bloated kind of thing where the last thing you'd want to do is edit it manually. I've dealt with cloudformation in XML form at some point in my life. It sucks. Not just a little bit. It's an absolute piss poor format for a thing like that. Since such a thing was lacking at the time, we ended up actually building our own little tools to generate that xml. Hand editing it was just too painful. One mistake could corrupt your entire stack. And it takes ages to find out if you actually got it right. In Json form it's hardly any better. It's just one of those convoluted over-engineered things. Anyway, Json support for cloudformation was not there at the time and the difference is like asking whether you'd preferred to be shot or stabbed. It's going to suck either way.
• yyyk 3y ago
  The problem is that document, serialization and configuration formats are different usecases and need different languages. We learnt that XML was a bit too verbose for serialization and moved to JSON. Now we need a good configuration format, especially for the advanced usecases, and YAML ain't it. The known ambiguities are a minor thing - the real problem is that it's not typed enough and significant whitespace. We need a language optimized for custom datatypes. That's why properly used XML is actually better here (it's better typed), but it's far from optimal. We could really use a different option.
• wodenokoto 3y ago
  So every xml file I’ve met has this boiler plate line at the top, something like: <?xml version="1.0" encoding="UTF-8"?> But more often than not, it also has a url. But so does every json file I get from Azure. The other day I exported a power app and each app parameter/variable has its own folder with an xml file and a json file all, which each reference versioned schema and all sorts of stuff all to essentially just say “key: value” Who does this and why?
  • hleszek 3y ago
    It is known as the XML declaration. It is not specific to any particular organization or group but is a standard part of the XML format itself. This declaration serves several important purposes: Version Information: It specifies the version of the XML standard being used. In this case, it's version 1.0, which is the most common version of XML. Character Encoding: It specifies the character encoding being used in the document. In this case, it's UTF-8, which is a widely used encoding that can represent a vast range of characters from different languages and character sets. Standards Compliance: It signals that the document adheres to the XML standard. This declaration helps parsers and software that process XML documents to interpret and handle the document correctly. Interoperability: By including this declaration, creators of XML documents ensure that their documents can be correctly interpreted and processed by a wide range of XML tools, libraries, and parsers. In essence, the XML declaration helps ensure that XML documents are self-describing and can be processed consistently by different software and systems. It's a crucial part of the XML standard and is included at the beginning of most XML documents to set the context for how the document should be handled.
• alkonaut 3y ago
  I don’t care which format is used for manual edits so long as it’s strict (no flimsy type coercions, possible to auto-format, possible to use a schema), and supports comments. For wire/data formats I don’t care at all. Perf/size and library support is the only factor there but xml or json will do up to the point when I can use protobuf or something similar. I don’t like the conventions/opinionated-ness of obit though. The absence of a set of things is usually not the same as an empty set of things, for example.
• baz00 3y ago
  I agree. YAML is hell. XML is just completely misunderstood. This one bit me recently. Parse it and see what happens. - yaml: - 01 - 08 This one works as expected: <list> <value>01</value> <value>08</value> </list> And I can qualify it <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="list"> <xs:complexType> <xs:sequence> <xs:element type="xs:string" name="value" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
  • angryzor 3y ago
    Ok but, just like the author of that article, you're just using the wrong datatype... You can easily get the desired behavior by quoting the strings: - yaml: - '01' - '08' Complaining about this is like complaining that { json: [01, 08] } will be interpreted as [1, 8] in json... It's not a problem with the tool, it's a user error.
    • roryokane 3y ago
      It’s not just user error – it’s a problem with the YAML format and culture. The YAML format allows most strings to be written without quotes. And YAML culture, as communicated through most YAML snippets in documentation and YAML files in the wild, is to take advantage of this by only adding quotes when necessary. That makes certain categories of user error much more likely. Someone might write `09` and confirm it’s a string, then change `9` to `7` and not notice that their string has turned into a number. The JSON format avoids this problem because it requires that all strings be quoted. If you start with `["09", "08"]` and change one of the digits inside the quotes, the string will stay a string. In JSON, strings becoming not-strings – removal of quotes or addition of backslash escaping – is more obvious than in YAML.
• KnobbleMcKnees 3y ago
  This is a bad take. Let me sum up. >>“I need to configure this server and the server needs to know if this value is true or false.” >No, that’s bad. Don’t do that. That’s not a good use for XML. First, the primary case that people use YAML for is not appropriate for XML? I don't agree with this but, taking it on face value, it creates a YAML strawman to attack. Second, the rest of the argument boils down to "I don't like how floats are parsed in my language of choice". Guess what? You're storing your version strings in the wrong data type. Stop storing semver and it's variants in floating point types, that's not what they're for. Finally, this is ultimately a "considered harmful" article, which is always a red flag.
• Mikhail_Edoshin 3y ago
  XML is very much misunderstood and this article is not an exception. XML is a notational tool. A notational tool is a tool for a human to write something by hand and then process with a computer. The important part here is “by hand.” E.g. I’m processing a corpus of someone’s letters and see a phrase like “on Monday I saw him the last time” and I know that I need to mark “on Monday,” “I,” and “him” with references to a date and people I have inferred from elsewhere, and the only way I can do this is by hand, there is no automation. Yet once I place those references, I can mechanically index the corpus, which is my goal. But writing a configuration file is the same task. Here again I am doing a thing that in the general case has to be done by a human, but the goal is to process the result mechanically. All other uses of XML are a misuse. Yes, you can use it for data interchange, but it is similar to programmatically calling a third-party tool via a command line. Possible, but involves much overhead and is way less convenient than using that tool via a library. If the data are not generally composed by hand, then they should not be in XML. (But I would argue they should not be in JSON or YAML either; we do this mostly because we have no suitable tools.) As a notational tool XML is actually rather good. Yes, it is verbose. You know what is not verbose? A special language you create for your special case. It will outperform any generic notation out there. If you decide to do that, then you will have to write a parser, process the text and get an abstract syntax tree. But note that XML is an abstract syntax tree. It is the intermediate result you get if you decide to solve your case in a perfect way. So maybe you could start with XML, get the syntax tree right, write the code to process it, and then see if you still want a parser. On XML verbosity: what if we compared not the overall length, but the number of syntactic symbols? <server id="a" ip="1.2.3.3" role="back" /> -- < "" "" ""/> {"id": "a", "ip": "1.2.3.4", "role": "b"} -- {"":"","":"","":""} I’ve extracted syntactic symbols on the right and you can see XML is much quieter. On XML not being mappable to objects and arrays: it is straightforward if you remember that the data are supposed to be a syntax tree. They are indeed far from the final representation in the same way an arithmetic expression is far from the code that will evaluate it.
  • eviks 3y ago
    Here is a quieter part <server id=a ip=1.2.3.3 role=back /> -- < /> why do you need quotes when you have nothing to quote (no whitespace etc)?
• bhawks 3y ago
  Configs for any mildly complex piece of software ends up looking like: 30% implicit defaults that are waiting to break when you upgrade something 25% boilerplate 20% derivable from some other configuration but you just gotta set them all explicitly 10% cargo culted in through copy-pasting from the last project 5% can only ever be set to one particular value or nothing works 5% silently ignored due to typos - (some of these are causing subtle bugs and some are preventing them) 3% critical to actually doing the thing 2% used to have an effect but that was 3 versions ago Of these flags and values only 40% have meaningful and correct documentation and 66% are different in staging and production but we are 85% sure that's ok. Yes XML, YAML, and JSON have a ton of warts, but a good part of the problem is how we layer configurability into software systems in the first place. The serialization format can only be blamed so much.
• eviks 3y ago
  Very shallow argument > And I think the fact that now everybody is writing React… and they’re writing it with JSX… and JSX is basically just inline XML… I think that shows that there are cases where actually XML is pretty good No, popularity does not imply quality
• globular-toast 3y ago
  > “test this against Go 1.20” ... It interprets that as Go 1.2 No... it doesn't... What the heck is this misinformation? num: 1.20 str: "1.20" str2: Go 1.20 str3: "Go 1.20" These all parse as strings except the first one. TOML also parses the following as number: num = 1.20
• deafpolygon 3y ago
  XML is a data exchange document. It's born out of being a mark-up language, but it's true strength is as a data exchange format that can be self-documenting and human-readable at the same time. Yes, it has a tendency to make people's eyes bleed with how verbose it can be. But if you were to open an XML file without knowing its format, or what each entry is supposed to be... it is likely you will understand (or be able to suss out) the purpose of the data being exchanged. Schemas are very powerful, well-documented, and can be used to validate that an XML document is well-formed. People who tend to hate XML and Schemas tend not to understand how or why this is needed. Contrary to the article's one point about config: I believe one of XML's strength is as configuration documents. It's better suited to configuration that is meant to be shared between different projects or platforms. If you only need a configuration file for a few keys and values - you're probably going to be fine with anything else. But if you need to dump a configuration file into a document to be read by another program or exchange, then you're better off using XML because that format is more tolerant and can be well-documented by using Schemas. You can version those schemas, and use XSLT to convert the configuration document into another format that is far more readable. That said, XML is not an be-all and end-all format for everyone. I believe, more importantly than anything, in using the appropriate tool for the given task. XML is simply not the best tool for every task.
• bArray 3y ago
  > > “test this against Go 1.20” > It interprets that as Go 1.2. In these types of configurations, _everything_ should be a string and data types are parsed with an additional helper function. It was a mistake to have per-platform, per-implementation parsing. > Now, I understand why people do YAML, but there are better choices. JSON. XML is great, but a little too verbose and can be difficult to parse. JSON is simple, well structured, easily human readable (if a sane structure is used), agnostic to indentation.
• ValtteriL 3y ago
  I recently developed a reporting feature to a system. The report had to be portable, both human and machine readable, and the human-part had to look nice to management people. I considered generating 2 separate reports, in JSON for machines and in PDF for humans. The PDF part turned out to be difficult. In the end I settled with XML. Its machine readable by nature and with XSLT it becomes human readable in the browser. The programming language provided XML encoder in the standard library which made the task very easy. I still find XSLT a pain to deal with though!
• bloppe 3y ago
  This is like saying apples are better than oranges. One is a document markup language. The other is a data notation. YAML is better understood as a family of notations at this point. For every gripe about the standard YAML implementation, there is a "safe" implementation that does not have that problem. You don't have the throw the readability baby out with the footgun bathwater.
• ramon156 3y ago
  XML, YAML and TOML all have their issues when expanding. No way around it
• indymike 3y ago
  YAML and XML both get their reputation from the software that use them poorly. XML is a pretty decent markup format. YAML is a decent serialization format. Both are brittle when used as a human edited configuration file format.
• salawat 3y ago
  I'm surprised no one has come up with PORN: Portable Object Reference Notation. Then we could have endless debates about the relative merits of our preferred styles/layouts of our favorite .porn files.
• runeks 3y ago
  The primary problem with YAML is that it allows writing strings without quotes. This causes confusion because it’s impossible to see, from just reading the YAML file, which strings become strings and which are interpreted as numbers or booleans. For example, the identifier blah is interpreted as a string; but 01 is interpreted as a number, which makes it equivalent to 1. Similarly the identifier nope is a string while no is the Boolean literal false, and there’s no clear indicator that the former is a string while the latter is a Boolean.
• metanonsense 3y ago
  I don‘t understand why HOCON (https://github.com/lightbend/config/blob/main/HOCON.md https://github.com/lightbend/config/blob/main/HOCON.md) isn‘t used more often (at least for configuration use cases). It‘s a superset of JSON, has comments, multiline strings, optional quotes, replacement syntax. We use it at many places, and it‘s as nice at it can get.
• bhaak 3y ago
  XML is better than YAML and JSON. No need to hear you out. But it's too hard for cowboy programmers to write valid XML.
• bullen 3y ago
  If you need a XML editor for Trees, Nodes or .png sprite sheets: http://move.rupy.se/file/logic.html http://move.rupy.se/file/logic.html I used it for DB schemas and game pixel art.
• p0w3n3d 3y ago
  To me XML isl like Hi I'm a singer. My name is: Paul my name is My last name is: McCartney my last name is My children are: My child is: Her name is: Heather her name is Her age is: 15 her age is ...my child is ...my children are ...I am singer
• afiori 3y ago
  The best config format is clearly GRON https://github.com/tomnomnom/gron https://github.com/tomnomnom/gron
• Tomis02 3y ago
  That's like saying long COVID is better than lung cancer.
• redhale 3y ago
  > It’s just too error-prone, there’s too many things… You just have to always quote everything. Sorry, but this seems like a very silly, petty argument. There are other reasons to not like today's pervasive use of YAML, but this is not a very compelling one imo. The same is true in XML, practically speaking, there just isn't another option - everything must be quoted or wrapped in tags. So just ... use quotes in YAML. You can force it through a linter [0] if the optionality is what you're hung up on. [0] https://yamllint.readthedocs.io/en/stable/rules.html#module-yamllint.rules.quoted_strings https://yamllint.readthedocs.io/en/stable/rules.html#module-...