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.
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.
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
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.
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.
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.
I believe XML has it baked directly into the official spec. JSONSchema is great, but I wouldn't call it a standard yet, and anecdotally I haven't seen it as often as I'd like in use (i.e. I either need to run kubectl --dry-run or use a separate third party solution to validate my changed yaml).
I once had an issue where something failed in prod but not in test, it was because a MAC address was dynamic and in prod only consisted of numbers so whatever tool we used parsed the Yaml value as a sexagesimal number and threw a type error. Yaml can be interesting…
Note that the behavior you describe (like the “NO” problem) was part of the YAML 1.1 excessive-effort-at-DWIM insanity (in this case, intended to make time entry “just work”) that was removed in YAML 1.2.
Pro tip: remember that all JSON is valid YAML. You can put JSON in a .yaml file and be just fine. I find that handy when the explicitness makes it easier to read the file.
I have. A ton of vendors and APIs generate XML with interpolation or some other form of hand-rolled code that’s incorrectly escaped, which compliant parsers can’t parse and they can’t fix.
I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousan... but the gist of it is that I had to parse thousands of blog feeds and some article from 2009 included a SOH control sequence inside of otherwise valid XML and this broke everything, until I added additional error handling.
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.
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.
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.
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
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.
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.
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.
My full sentence is more like saying Java is untyped if it were possible to run Java source files from the AST while skipping the type validation step, which seems pretty much a truism to me.
The problem isn't that XML's decimal type doesn't distinguish between 1.2 and 1.20 - it's that versions aren't decimals in the first place.
The fact that versions often contain numbers separated by decimal points or that often times, versions only have two components or that minor versions may rarely exceed 9 for a particular product are merely coincidences.
I don't understand why you are being downvoted. You're absolutely right, though I'd nitpick and say not say "untyped" but that the only types that XML gives you are dom nodes and strings.
Contrast that with JSON, which provides booleans, numbers, and the list and object composite types. (side rant: as a standard JSON does not define whether it's numbers are integers, floats, or decimals! a conforming implementation can use whatever type it wants).
Yes, XML has (multiple) schema definition languages that can be used to enforce that the strings can be coerced into specific types, but XML itself conveys no type information in-band about the values. I think this is one of the reasons it is difficult read and write by hand.
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.
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.
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?
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.
>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.
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.
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.)
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.
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.
In my experience you have to have the duplication before you factor it out; trying to design those terms up front when you have no use cases, or even one use case, is doomed to failure. So you're always going to need to start with something non-standard, figure out the standard based on that experience, and then migrate to align to the standard.
Right, this is pretty much exactly what I meant by XML started with all the complexity that other things will add.
I will happily cede that data is a huge area where "duck typing" is far and away the correct choice. Taxonomies of data fail all the time. With odd rules that are largely defined by their exceptions.
XML is full of complexity that it shouldn't have and any competitor would be stupid to adopt.
For example, either your format is a programing language, or the data evaluation must never need an internet connection. XML isn't one, yet still requires it.
If you want to implement the standard, you parser must be prepared to download extra data when the file requires (it doesn't actually need to download schema, even though it's the naive way to implement it).
A lot of parsers do not implement the standard, and they are better for it, because this can create huge security issues. But it's something you have to be always aware of, and could change on any minor version update.
Right, if you are willing to validate any and all random documents, you will have to have some sort of way to get the schemas. I can think of very few reasons to validate unknown schemas in an application, though. Would be like allowing your parser to take in external entities. Can be useful and there are valid reasons for trusted sources. But not for random documents from the web.
"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…"
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?)
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)?
Not quite unambiguous! It declares how to parse numbers, but of course the "reference implementation" of JSON (insofar as there is one) is Javascript, in which numbers are floats and hence e.g. are bounded in precision, so the spec actually disagrees with the reference implementation.
I don't think this is true. The original specification (ECMA 404) only covers the formal language, i.e. what are valid documents and not what their memory representation after deserialisation is. A parser that rejects a number because it has too many digits would not be conforming.
rfc8259 is more detailed and it mentions that most parsers will have limited precision and references ieee754 to explain what the expected precision after deserialisation should be for most parsers.
It is, but then you just use JSON, and can ignore YAMLs design issues and broken design, plus benefit from the mass more readily available and faster parsers!
The fact that JSON doesn't support comments is so annoying, and I always thought that Douglas Crockford's rationale for this basically made no sense ("They can be misused!" - like, so what, nearly anything can be misused. So without support for comments e.g. in package.json files I have to do even worse hacky workaround bullshit like "__some_field_comment": "this is my comment"). There is of course jsonc and JSON5 but the fact that it's not supported everywhere means 10 years later we still can't write comments in package.json (there is https://github.com/npm/npm/issues/4482 and about a million related issues).
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.
“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?
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.
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>
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).
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.
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/):
[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.
> 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.
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.
Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql)
> the syntax too quirky
Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward.
> Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql)
What is a "number"? Is it a float? int? short? double? BigDecimal?
What about time values? Or dates? Oh, you have to just shove those into strings and hope both sides agree? That's fun.
> Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward.
One example is the json "spec" on json.org does not allow trailing commas yet many parsers do
> 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.
XML's validation, schemas and typing are far more complicated and equally useless - the impedance mismatch is too big, all they do is give you a whole bunch of extra ways to shoot yourself in the foot, particularly in the presence of namespaces. If you want something fully structured, protobuf or equivalent is the way to go (and converting back and forth between protobuf and JSON is relatively painless).
XML Namespaces are one of the worst anti-features I have ever encountered. I have yet to see a legitimate use for them, but they make parsing way more of a pain than it needs to be.
Also the use of attributes vs nested tags seems pretty arbitrary and in my experience attributes are hardly used at all.
Yeah, I personally find XML elegant and well-designed compared to the popular alternatives today. And things that supply what’s missing (for example, JSON-LD and JSON Schema) aren’t much less complicated than the XML equivalents.
Of alternatives, I think EDN is the closest to being a satisfactory replacement because it supports namespaces.
# Diff for interactive merges.
# %s output file
# %s old file
# %s new file
merge="sdiff --suppress-common-lines --output='%s' '%s' '%s'"
it's useful the first time you dive in, not having to read the man page. But over time, the comments can get out of sync especially if you don't carefully merge in the package-maintainer's version every update.
They have a parse.y that sort of gets traded around and joins new projects. Nothing super formal but it does mean most openbsd service configuration feels like each other. but each config is tailored to it's application. and being properly parsed the error messages can be better.
In fact that is my biggest beef about yaml, I mainly use it in the context of ansible, and the parsor usually has no clue where in the file the error actually is. You have to depend on remembering where you last edited to actually find the error. My other big problem with yaml is that the ansible context is trying very hard to make it a programing language... And while it is an okish config language it is a terrible programing language.
In fact this is a common problem with many complex environments. They want to try and push this complicated setup into a config file and claim "look it is easy, no programing required" when really what they have done is to push a programing situation into the worlds worst programing language. see also: xslt
For human-maintained config, TOML is only "better" when the structure is so flat that it's almost indistinguishable from an INI file.
Anything more complex and it becomes one of the worst choices due to the confusing/unintuitive structure (especially nesting), on top of having less/worse library support.
YAML's structure is straightforward and readable by default, even for fairly complex files, and the major caveats are things like anchors or yes/no being booleans rather than the whitespace structure. I'd also argue some of the hate for YAML stems from things like helm that use the worst possible form of templating (raw string replacement).
I'm with you on all that. I think YAML's fine, and I like it way more than TOML for non-trivial files.
I think Python's pyproject.toml is a great use of TOML. The format is simple with very little nesting. It's often hand-edited, and the simple syntax lends itself nicely to that. Cargo.toml's in that same category for me. However, that's about as complex of a file as I'd want to use TOML for. Darned if I'd want to configure Ansible with it.
Agreed, I do a lot of Ansible, and it took me a while up front, but I've become pretty accustomed to YAML. Though I still struggle with completely groking some of the syntax. But, I recently took a more serious look at TOML and felt like it'd be a bear for Ansible.
A few months ago I made a "mini ansible / cookie cutter" ( https://github.com/linsomniac/uplaybook ), and it uses YAML syntax. I made a few modifications to Ansible syntax, largely around conditionals and loops. For YAML, I guess I like the syntax, but I've been feeling like there's got to be a better way.
I kind of want a shell syntax, but with the ansible command semantics (declarative, --check / --diff, notify) and the templating and encryption of arguments / files.
“Nesting is bad” is such a simplistic take. Nesting is absolutely essential and inescapable. What that statement is really doing is placing a limit on what whatever it applies to can be used for. It would be better to spend a few more words expressing what you really mean.
Your comment is a simplistic take on "Nesting is bad" given the context.
It's not hard to infer that they're referring to nesting as a footgun: make it harder and you lose some power but you keep your feet.
Config files are a poor place to complex and deeply nested relationships. If it's not ergonomic to reach for nesting people tend to be forced to rethink their approach.
The problem is "config" means different things to different people. Some people see config as "the collection of runtime parameters" basically a bank of switches: Pyproject.toml is config. Others see any form of declarative structured data ingested by a runtime as config: docker-compose.yml is config.
And of course to minimize impedance mismatch, the structure should be similar to the domain.
So yes I want a "config file" to handle at least a dozen levels of nesting without getting obnoxious.
Then I guess to frame it in your language: they want formats that encourage config files, not "config files".
And I don't disagree. The problems of nesting objects "at least 12 levels deep" aren't going to be solved by the right format. The tooling itself needs to expose ways to capture logical dependencies other than arbitrary deep K-V pairs.
What if your problem is best expressed as "arbitrary deep K-V pairs"? It's going to be more common than not, nesting really is that fundamental.
There is no escape, you can't win. If you want the nesting, and assuming you can't remove it from the problem itself (as you often can't, or at least shouldn't), there's only one thing you can do: move inner things out, and put pointers in their place. This is what we do when we create constants, variables, and functions in our code: move some of this stuff up the scope, so it can be used (and re-used) through a shorthand. It loses you the ability to see the nesting all at once, but is necessary (among other reasons) when the nesting is too large to fit in your head.
Of course once you do that, once you introduce indirection into your config format, people will cry bloody murder. It's complex and invites (gasp) abstraction and reuse, which are (they believe) too difficult for normies.
The solution is, of course, to ignore the whining. Nesting is a special case of indirection. Both are part of the problem domain, both are part of reality. Normies can handle this just fine, if you don't scare them first. You need nesting and you need means of indirection; might as well make them readable, too. Conditionals and loops, those we can argue about, because together they give a language Turing-complete powers, and give security people seizures. And we have to be nice to our security people.
This is whining that people won't endorse a lazy, poorly scaling approach to an engineering problem... and justifying that approach by conjuring hypothetical whiners against a common, better scaling solution.
If you need 12 levels of nesting, add indirection, or live with the fact no one is designing formats to enable your oddball mess of a use case.
12 levels of nested braces in a single function is already a crappy idea: it's an even more crappy idea in a config file because of the generally inferior tooling, and now there's a downstream component that needs to change to support a cleanup (meaning it almost never gets fixed and the format just gets worse over time)
> For human-maintained config, TOML is only "better" when the structure is so flat that it's almost indistinguishable from an INI file.
Agree. I've recently inherited a python project, and I'm already getting tired of [mentally.parsing.ridiculously.long.character.section.headers] in pyproject.toml.
Seriously, structure is good. I shouldn't have to build the damn tree structure in my head when all we really needed was a strict mode for YAML.
> I'd also argue some of the hate for YAML stems from things like helm that use the worst possible form of templating (raw string replacement).
I was literally speechless when I saw helm templates doing stuff like "{{ toYaml .Values.api.resources | indent 12 }}", where the author has to hardcode the indentation level for each generated bit of text like a fucking caveman.
The tiny examples might look kinda okay, but when someone has stacked 10 different patch operations in a single file, it gets a lot harder to keep track of what's going on.
An flat toml file is indistinguible from ini except one point: you can create an pure key value file without sections but not with the most ini parsers i saw.
in terms of something i'm shipping to users, i would much rather have to worry about the nuances of TOML than of YAML. with TOML, i don't have to worry about e.g. remote code execution because someone figured out a clever way to trick my yaml into running arbitrary code somehow. that kind of shit is annoying.
is it uglier? sure. but it's peace of mind...
in terms of config i'm using myself, say Kubernetes stuff, i really love YAML...because i know exactly what it's doing and i generally keep things simple. it's nice for that, it just does way too much IMHO...
No no no, k8s mistake was actually not using YAML hard enough. They built an object system on top of a format that can act as a typed serialization format for generic objects and then decided to just ignore all that and implement it on top of primitive types
Tangentially: there are some objects in the Kubernetes configuration that require the data to be base64 encoded (I think it's secrets and config maps, probably something else). When I was preparing for my CKA certification, I used the (most?) popular course that introduced base64 encoding as a _security measure_. I think that also says something about the state of the industry.
{
"servers": {
# Frontend server is called alpha
"alpha": {"ip": "10.0.0.1", "role": "frontend"},
# Backend server is called beta
"beta": {"ip": "10.0.0.2", "role": "backend"},
}
}
Or, depending on your preference:
servers:
# Frontend server is called alpha
alpha:
ip: "10.0.0.1"
role: "frontend"
# Backend server is called beta
beta:
ip: "10.0.0.2"
role: "backend"
All of them suck in their own way. All of them work fine with autocomplete, type analysis, and autoformatting. The more things change, the more they stay the same.
JSON lacks comments, that's the biggest differentiator in my opinion.
JSON5 does, but most software just does plain and simple JSON. I haven't seen it used outside some Javascript webdev environments. The JSON5 docs also seem to be specifically targeting Javascript development.
If you're sticking to certain variants, you may as well use YAML, which supports JSON notation, as well as comments and various other improvements.
If you use python, there is an excellent json5 module. But true, it may not be as well supported by other languages.
I am not sure I may as well be using yaml. I don't like it for the multiple reasons in the OP and this thread.
If you are using python, I have found it to be quite easy to support both json5 and yaml, as well as converting between them for people who feel strongly about yaml. Not trivial but low effort.
I've gotten bit by trailing commas enough times (both manual edits and writing generators) that I absolutely expect any reasonable syntax to tolerate them. It's just so much easier and more consistent to tolerate them.
It does. However, it’s much more common to edit the end of a list, in my experience. Still, a syntax that is entirely uniform (like trailing commas) is preferable, in my opinion.
That's what Clojure got right. Comma is whitespace. When you print a datastructure, it has commas. But they don't effect reading of that structure. Its brilliant and practical.
- introduce the least idiomatic form of YAML as "depending on preference"
- add an optional preamble to the XML example
- add comments when there were none, but also not to all of them
If you didn't artificially stretch the different examples to match, there'd be a much clearer difference between them all, especially considering the fact one of your three examples is a superset of the other.
The odd one out can't even capture an integer vs a string without a schema.
I was puzzled by the GP's choice to write the first YAML example in a completely unidiomatic way.
But I think the point of adding comments was just to show that comments are possible in some formats, and not others. Omitting possible comments from the XML example might have just been a sign of fatigue over this topic ;)
At any rate, I find the (idiomatic) YAML example to be -- by far -- the most readable of all, including the GGP's TOML example.
- To showcase to the many people who aah JSON is more legible that you can use YAML as "legible" JSON
- Most XML files I encounter come in this format. You can skip the preamble but it wouldn't match my real life experience.
- All readable config files I encounter have comments. I forgot to add comments to the XML representation, but I can't edit my comment anymore. I think everyone who ever encountered XML knows how to add comments, though. JSON simply doesn't support comments unless you use a niche JSON derivative.
As for the string versus integer problem: you always need a schema, or you'll run into very funny problems down the line. None of these formats intrinsically know what keys refer to an object and what keys refer to a string, that's all based on your schema anyway.
"10" is a string. 10 is a number. [10] is a single number in an array. {"number":10} is an object.
You're conflating advice for databases with advice for data serialization formats: XML captures less information about the data it contains intrinsically.
_
Also please don't use YAML as "JSON with comments", you're just asking to run into some obscure bug/corner case
If you're willing to do weird things there's always JSON5
Your YAML example doesn't need double-quotes around the IPv4 addresses, but then very confusingly and problematically does need double-quotes around an IPv6 address, due to the colons.
This creates a serious footgun in Ubuntu netplan, leaving a server totally unbootable, but simultaneously not triggering "netplan try" as any sort of parsing problem:
And Javascript doesn't need semicolons in all but three exceptional cases, but I still consider it good form to strongly type values whenever possible.
Getting in the habit of not doing so will lead to schema violations, like the Netplan problem you linked, which can crash the program trying to read your config. If it bails out at an unfortunate time, like most networking tools seem to do, you'll need to use a recovery boot image or serial console to fix your config.
> This creates a serious footgun in Ubuntu netplan, leaving a server totally unbootable, but simultaneously not triggering "netplan try" as any sort of parsing problem:
Been there, done that. A good config file or linter should’ve complained and not allowed me to commit such misstake.
JSON is by far the easiest to reliably parse. It doesn't rely on tabs or spaces which YAML suffers from. XML is just more verbose JSON without an array object, and has some redundancy in spec which is not a good design.
Lack of comments for JSON isn't a huge issue considering you can make the keys fairly verbose. And it would be actually pretty easy to add this into the spec, and parsers would still be backwards compatible.
It's my preferred configuration file format, it fixes all the problems I have with JSON (trailing commas, comments) without turning it into a mess full of gotchas like YAML.
A theory - they don’t want a third party code in a hot path (they do care about performance in vscode), they already have a very performant parser and they don’t want to add a complexity there.
All of them are easy to parse. I personally prefer the clarity of indented YAML over the endless nesting of {} JSON brings, but all formats are easy enough to read or write.
Lack of comments in JSON is a huge problem for config files. It's not an issue if you're just exchanging data between APIs, but for config files, comments are essentials.
There are some JSON specs that will do comments, but they rarely specify what dialects of JSON their parser accepts. There are also workarounds that abuse the fact duplicate key handling isn't part of the spec by specifying each key twice, once with a comment and once with data as most parsers only make the second key stick; those are even worse.
You can't add backwards compatible comments to JSON, there's no space in the JSON spec to retroactively insert comments somewhere. The closest you can do is the duplicate key trick, but as the spec doesn't state which of the keys to read as a value, that trick only works with specific parser implementations.
YAML has newlines that indicate the end of a field... unless otherwise specified, which then gets into issues with line endings. Indents can also cause issues, considering a space inserted somewhere by accident can mess up your whole document. JSON and XML rely on specific tags for elements, which are much more reliable, and thus easier and faster to parse.
You can easily add comments to JSON spec, by just writing every parser going forward with the added comment parsing. It would read old JSON non commented files just fine.
None of them handles it well. YAML has 7 different modes to do it so you will inevitable mix up and use the wrong one, otherwise it's actually the only option that supports it. Json requires inlining \n. Xml only does it with whitespace indentation.
I love it. Was so happy to see that syntax when I first encountered Toml. Hierarchy is always clear without having to scroll, and snippets retain context.
And yet it's the only one out of all those mentioned that can be written with ease by humans. After a short while you can do several levels of nesting without thinking about it. For all its issues, it's by far the most practical which is why it won.
Practical but incorrectly used. We should correct the misunderstanding so that people don't continue to make similar mistakes, inconveniencing themselves and others.
i agree, while YAML has its problems, it is good for human-written content, especially when it's not too deeply nested.
in short: all these have their use-cases. i use YAML where it fits and TOML where it fits better. I never use JSON because JSON is just for machines, I generate JSONs.
> I'd echo the linked article's argument back: I don't know of a case where XML is the best option.
From the article:
> “I’m making a new kind of book, and I need to annotate all of the verses in the Bible, and have the chapter headings and stuff.”
XML is a markup language, and works great for marking up text. It came out of SGML and attempts to make machine-usable documentation.
I'd favour its use in something like a datasheet, which is a combination of human-readable information, nested objects, and lots of stuff that needs to be machine parseable in fairly precise ways.
IMO it also works "fine" for other structured document formats that aren't text, like SVG, but that's not a strong opinion. JSON and other formats compete more sensibly here, but I'd never want a protobuf-based format for... writing an essay, for example.
XML is pretty good for information extraction with LLMs. It will parse your input text into a tree structure. JSON and YAML will conjure slightly different skills from the LLM. Maybe it all comes from the slightly different applications of these formats in the training corpus.
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.
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".
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.
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.
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
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.
My motivation is expressing docker-compose.yaml in the "best" way I can imagine, as a design exercise. In that case, I'd rather have a bunch of (service ...) forms, instead of a "services" object. Not sure why. Maybe it's a pun on interpreter-driven formats like that used by [guix][1].
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)
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
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.
Yeah, I often go that route when embedding objects in YAML. I haven't gone full JSON yet, but it's very tempting. A downside to that is having to convert back to YAML if you need support or want to easily diff against configs other folks have shared.
I totally agree. I've used YAML for small config files on various projects I've written over the years. Stuff where it's maybe 50 lines on the extreme end, with a very simple data layout that doesn't get more than 2-3 levels deep. And for years and years I never understood WTF people were on about when they said how awful YAML is.
Then I used k8s for the first time. And after that, I understood, because k8s manifests are an abomination. Super error prone and hard to read. And I think that this has a whole lot more to do with the data model than the markup format. YAML isn't perfect (in particular, the way you specify an array of dicts is hot garbage and confusing), but it's not the main problem. The way the data is laid out in k8s would be awful to work with in any format.
> 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.
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.
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.
> 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.
> This is not a YAML problem, this is a “code that accepts and implicitly converts invalid data problem”.
No, this is a YAML problem, because YAML is specified to allow for unquoted strings, and then it uses heuristics to decide if you meant a string or a number or (god forbid) a boolean.
So the "code that accepts..." that you're talking about is literally every conforming YAML parser out there. And they do that because the spec tells them to. So yes, it is a YAML problem.
And to top that off, most of the examples and tutorials you'll find on how to use YAML don't quote their strings. I get the idea: fewer characters to type, more human readable. But god it's a minefield.
"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.
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.
Man, I wish I didn't need DTDs. Unfortunately, the USAF TMCR says I do. Verbatim. TO-00-5-3.
Yeah, in retrospect Billion Laughs was a bit of a cheap shot. It is, however, hilarious. And no one ever put forward any sort of mitigation or fix, for decades[1]. Meanwhile, in the YAML dev world open issues . .
if (refDepth > maxRefCount && node.kind === Yaml.Kind.ANCHOR_REF) {
I don't really have a dog in the YAML fight - apart from Asciidoctor-pdf template files[1] - but the YML people are patching, and the XML people didn't, for a very long time.
Why is that? I'm going to go back to the basic notion of XML as the Everything for Everything, which was encouraged by its design pattern insistence on fake semantics. YML has, no doubt, a big ol' dose of the same sickness, but with a lot less overhead, and it makes maintenance easier.
Keep in mind, we're now debating "How YML is perhaps just as bad as XML"
[1] This has resulted in a lot of software and IETM files (even whole devices) getting pulled from USN vessels in theatre; there's more than a few vulnerabilities that ride on the SGML/DTD Billion Laughs. Bunch of other ancient file formats getting the same treatment, something we in the industry saw coming since 2007. Just a ticking bomb until you fight a peer.
Not a whole lot. And not just XSD, there's nothing either SGML or XML do that can't be done, fifty times faster, with fewer keystrokes, on standard - i.e., commodity, open - tooling, in Asciidoc (as it's deployed) or "Markdown" (with extensions).
USAF hasn't yet gotten nailed with the DTD attacks the way the USN was[0]. And that was a complete musterfluck. First they pulled all the handheld maintenance devices, then they basically mandated that all the stuff getting stuffed into entities could instead get shoved into a black box XML element stuffed full of Base64 or reference to an external binary or - hell - whatever you want. That's the current solution: the //multimedia element.
You'd think USAAF and USAA[1] would have learned something from this . .
[0] That's changing as we speak; DIA has a bunch of hardass new IT policies rolling out. God be praised.
[1] Although the USAA spec has more flex in it when it comes to geometry and other extremely specific rendering behaviors. It's much easier to optimize because it's not insistent that a frickin PDF parts catalog have draftsman-perfect line art.
Here's what the entities (specifically, CGM, the 800 lb gorilla of external entity references) do that can't be done in XML+SVG: ISO/IEC CGM:1999 line types (your dashed lines are exactly right); ISO/IEC CGM:1999 nurbs (so that the curves are just right). I have a bunch of counterarguments to these things and more, but the easiest one is : how much is a perfect dashed line worth? Is it worth twenty two million dollars? Because that's what it cost the Navy. That's assuming the PLAAF/PLAN doesn't hop inside your maintenance network off the east coast of Taiwan. Then you can buy your dashes at the reasonable cost of a few hundred dead sailors.
They need to swap out //multimedia for a standardized, text-based format yesterday, though. Either that or release an ISO profile for SVG, which honestly would be, like, a week's worth of work at most . . if you wanted to see it done, of course. Oh ISO Technical Steering, you and your loveable scamps made up almost entirely of stoneage software industry reps.
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.
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/ 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.
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?
It's a perfectly reasonable serialization format and works fine as such. It does not work well as a configuration format, because humans are not supposed to write it by hand.
> It's not YAML's fault they didn't quote their numerical strings.
Yes, it is. If you design a format in such a way that type parsing is ambiguous, or in this case "keep trying to parse it over and over, starting with the most restrictive option and working your way down", people are going to commit errors. That's just life.
I would absolutely love it if YAML parsers supported a mode where quoting your strings was required. Or, while I'm wishing: a new YAML version that requires that (even though that's impossible to do backward-compatibly without yucky things like having to specify the YAML version in the document itself).
But I do still use YAML for config files, because there's enough about the other options that I don't like even more than YAML.
Replying to my own comment. Just read through the TOML spec for the first time in years and its tables are essentially dictionaries. Don't know if that was added later or if I just missed it earlier. I'll consider using TOML for future projects. That said, I still think some of the hate YAML gets is unwarranted.
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.
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.
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.
I've broken plenty of networks by adding typos to /etc/network/interfaces and then running ifdown;ifup. Misconfiguration can happen no matter what format your config files are in.
Yes, without the quotes, the IPv6 address gets interpreted a YAML mapping/dict because of the colon(s).
Perhaps the trap is the complacency that YAML induces by not requiring quotes around keys/values, and so text risks being interpreted in unexpected ways. The infamous Norway Problem has the same root cause.
Even in the first position? That makes it no longer be the claimed "superset of JSON", since (AFAIK) {"key":"value"} (with no whitespace) is valid JSON.
For delimited collections, so within {} and [], if the key is quoted, then you don't need the whitespace. So your example parses as expected as does `{"key":value}`, but `{key:value}` turns into `{"key:value": null}`.
That's odd. Looks like Netplan looks like uses libyaml, and vanilla libyaml definitely parses that naked v6 addr as a plain scalar. Maybe Netplan adds an extra schema on top or something? If you know what data the bare v6 string turned into, I'd love to hear it.
Yaml is like JSON, in that the format requires you to think about strings vs integers.
I bet the parser did actually fail, because you can't parse a misformed dictionary into a string. Your problem is that the tool probanlt took down the interface before trying to parse for format, and then failed to bring the interface back up.
Similar to bogus data in /etc/network/interfaces, resetting the network interfaces with bogus data will end up with your server having no or limited connectivity capabilities.
At least with YAML there are command line parsers available to check your work. Plaintext config files often end up being a game or chance to see if you've got the format right.
In my rather short experience with netplan, I found:
As above, you can’t ask netplan to sanity check a config.
You can’t create a draft configuration, apply it, and save it if it works well. Every self-respecting network config system since at least Cisco IOS can do this (and does it by default!).
Interface renaming can’t filter by being a physical interface, which means that the system tries, and fails, to rename VLANs, because their MAC matches something that should be renamed. (networkd can handle this, but the networkd config written by netplan is wrong.)
Deleting virtual interfaces (e.g. VLANs) seems to be essentially unsupported, at least on 20.04. I think it’s slightly, but only slightly, better in newer releases.
Ouch, quite a lot of 'learning'! Color me unimpressed, too.
I've grown to enjoy NetworkManager. I know, like all things, that is probably controversial to some.
Two things I really appreciate about it:
- You can 'up' a connection/interface in an idempotent way; only changing whatever is needed.
- it's *very* scriptable. Values can be given with +/- operators
I was surprised/frustrated with networkd initially, but enjoy it now.
It getting involved with packet forwarding was an unwanted surprise during a modernization effort.
When you have a linux-only scenario - say on your laptop, and servers, which is my case - innernet's simplicity and fairly-good elegance is tough to beat.
As soon as Windows/MacOS/Android/iOS clients want in on the fun, alas, you'll need something more complicated than innernet to accommodate these other clients.
Unpopular opinion I guess, but I really like netplan. I like having the vlan, bonding, ip, routing, dns configs all in one place, and it's worked well for me over 4-5 years.
644 comments
[ 4.5 ms ] story [ 378 ms ] threadHumans can screw up anything. And more text often allows it to hide for longer.
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.
JSONSchema? It's pretty standardized and well accepted.
All JSON evaluates to some value in YAML. But it's not always the value you want it to.
Oh hey, I had some while making https://hn-blogs.kronis.dev/
I wrote more about it on my blog: https://blog.kronis.dev/articles/ever-wanted-to-read-thousan... but the gist of it is that I had to parse thousands of blog feeds and some article from 2009 included a SOH control sequence inside of otherwise valid XML and this broke everything, until I added additional error handling.
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.
But, I agree that this is one of the worst parts of XML
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.
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
this is like saying Java is untyped because the source files are just text
My full sentence is more like saying Java is untyped if it were possible to run Java source files from the AST while skipping the type validation step, which seems pretty much a truism to me.
The fact that versions often contain numbers separated by decimal points or that often times, versions only have two components or that minor versions may rarely exceed 9 for a particular product are merely coincidences.
Contrast that with JSON, which provides booleans, numbers, and the list and object composite types. (side rant: as a standard JSON does not define whether it's numbers are integers, floats, or decimals! a conforming implementation can use whatever type it wants).
Yes, XML has (multiple) schema definition languages that can be used to enforce that the strings can be coerced into specific types, but XML itself conveys no type information in-band about the values. I think this is one of the reasons it is difficult read and write by hand.
I am searching for this, any clue ?
However, before you start, there were bugs that I found, and Augeas is a bit hard to work with.
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.
"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.
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.
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.)
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.
I will happily cede that data is a huge area where "duck typing" is far and away the correct choice. Taxonomies of data fail all the time. With odd rules that are largely defined by their exceptions.
For example, either your format is a programing language, or the data evaluation must never need an internet connection. XML isn't one, yet still requires it.
A lot of parsers do not implement the standard, and they are better for it, because this can create huge security issues. But it's something you have to be always aware of, and could change on any minor version update.
So, agreed it is a bit of a footgun.
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…"
When the schema says so — you even get auto-complete for that in any half-decent editor.
rfc8259 is more detailed and it mentions that most parsers will have limited precision and references ieee754 to explain what the expected precision after deserialisation should be for most parsers.
Its spec is not "complete and unambiguous"!
Non ambiguous structure, parsable, nested values, lists, maps, and so on.
If JSON had comments it would be ideal - and for configuration you can support it.
Just check VS Code for what is possible to do directly regarding configuration with JSON, and also to build on top.
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.
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?
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.
This makes sense:
This does not: That should be:Not to mention "you're holding it wrong" is seldom a good argument.
Would you mind reading the rules at https://news.ycombinator.com/newsguidelines.html and sticking to them when posting here? We'd appreciate it.
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.
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.
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.
Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql)
> the syntax too quirky
Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward.
What is a "number"? Is it a float? int? short? double? BigDecimal?
What about time values? Or dates? Oh, you have to just shove those into strings and hope both sides agree? That's fun.
> Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward.
One example is the json "spec" on json.org does not allow trailing commas yet many parsers do
XML's validation, schemas and typing are far more complicated and equally useless - the impedance mismatch is too big, all they do is give you a whole bunch of extra ways to shoot yourself in the foot, particularly in the presence of namespaces. If you want something fully structured, protobuf or equivalent is the way to go (and converting back and forth between protobuf and JSON is relatively painless).
Also the use of attributes vs nested tags seems pretty arbitrary and in my experience attributes are hardly used at all.
So. Many. Conflicting. Namespaces. Often for the same “kind” of document, at least as far as the user is concerned.
So much flexibility. So many ways to paint yourself into a corner. Such a nightmare.
Also, the reason we have jobs.
Of alternatives, I think EDN is the closest to being a satisfactory replacement because it supports namespaces.
I don't like XML, YAML, or JSON.
If I am doing server-side PHP, my config files are executable PHP. It's my responsibility to make sure they can't break the system too much.
If I am doing host-side stuff (like Swift Package Manager), I prefer executable Swift files.
But I cut my teeth on BNF[0], and X.500[1]. They worked well, but were painful. They make YAML look good.
[0] https://en.wikipedia.org/wiki/Backus–Naur_form
[1] https://en.wikipedia.org/wiki/X.500
Comments that result in:
cause me to die.I tend to preface my config stuff with fairly substantial comment blocks that discuss the reasoning behind the configuration.
Here’s an example: https://github.com/LittleGreenViper/LGV_MeetingServer/blob/m...
They have a parse.y that sort of gets traded around and joins new projects. Nothing super formal but it does mean most openbsd service configuration feels like each other. but each config is tailored to it's application. and being properly parsed the error messages can be better.
In fact that is my biggest beef about yaml, I mainly use it in the context of ansible, and the parsor usually has no clue where in the file the error actually is. You have to depend on remembering where you last edited to actually find the error. My other big problem with yaml is that the ansible context is trying very hard to make it a programing language... And while it is an okish config language it is a terrible programing language.
In fact this is a common problem with many complex environments. They want to try and push this complicated setup into a config file and claim "look it is easy, no programing required" when really what they have done is to push a programing situation into the worlds worst programing language. see also: xslt
Not without a trauma therapist on speed-dial.
Anything more complex and it becomes one of the worst choices due to the confusing/unintuitive structure (especially nesting), on top of having less/worse library support.
YAML's structure is straightforward and readable by default, even for fairly complex files, and the major caveats are things like anchors or yes/no being booleans rather than the whitespace structure. I'd also argue some of the hate for YAML stems from things like helm that use the worst possible form of templating (raw string replacement).
I think Python's pyproject.toml is a great use of TOML. The format is simple with very little nesting. It's often hand-edited, and the simple syntax lends itself nicely to that. Cargo.toml's in that same category for me. However, that's about as complex of a file as I'd want to use TOML for. Darned if I'd want to configure Ansible with it.
A few months ago I made a "mini ansible / cookie cutter" ( https://github.com/linsomniac/uplaybook ), and it uses YAML syntax. I made a few modifications to Ansible syntax, largely around conditionals and loops. For YAML, I guess I like the syntax, but I've been feeling like there's got to be a better way.
I kind of want a shell syntax, but with the ansible command semantics (declarative, --check / --diff, notify) and the templating and encryption of arguments / files.
It's not hard to infer that they're referring to nesting as a footgun: make it harder and you lose some power but you keep your feet.
Config files are a poor place to complex and deeply nested relationships. If it's not ergonomic to reach for nesting people tend to be forced to rethink their approach.
And of course to minimize impedance mismatch, the structure should be similar to the domain.
So yes I want a "config file" to handle at least a dozen levels of nesting without getting obnoxious.
And I don't disagree. The problems of nesting objects "at least 12 levels deep" aren't going to be solved by the right format. The tooling itself needs to expose ways to capture logical dependencies other than arbitrary deep K-V pairs.
There is no escape, you can't win. If you want the nesting, and assuming you can't remove it from the problem itself (as you often can't, or at least shouldn't), there's only one thing you can do: move inner things out, and put pointers in their place. This is what we do when we create constants, variables, and functions in our code: move some of this stuff up the scope, so it can be used (and re-used) through a shorthand. It loses you the ability to see the nesting all at once, but is necessary (among other reasons) when the nesting is too large to fit in your head.
Of course once you do that, once you introduce indirection into your config format, people will cry bloody murder. It's complex and invites (gasp) abstraction and reuse, which are (they believe) too difficult for normies.
The solution is, of course, to ignore the whining. Nesting is a special case of indirection. Both are part of the problem domain, both are part of reality. Normies can handle this just fine, if you don't scare them first. You need nesting and you need means of indirection; might as well make them readable, too. Conditionals and loops, those we can argue about, because together they give a language Turing-complete powers, and give security people seizures. And we have to be nice to our security people.
If you need 12 levels of nesting, add indirection, or live with the fact no one is designing formats to enable your oddball mess of a use case.
12 levels of nested braces in a single function is already a crappy idea: it's an even more crappy idea in a config file because of the generally inferior tooling, and now there's a downstream component that needs to change to support a cleanup (meaning it almost never gets fixed and the format just gets worse over time)
Agree. I've recently inherited a python project, and I'm already getting tired of [mentally.parsing.ridiculously.long.character.section.headers] in pyproject.toml.
Seriously, structure is good. I shouldn't have to build the damn tree structure in my head when all we really needed was a strict mode for YAML.
> I'd also argue some of the hate for YAML stems from things like helm that use the worst possible form of templating (raw string replacement).
I was literally speechless when I saw helm templates doing stuff like "{{ toYaml .Values.api.resources | indent 12 }}", where the author has to hardcode the indentation level for each generated bit of text like a fucking caveman.
This is by far the worst use of YAML I've seen, but I'd nominate kustomize for an honorable mention. Most of the various was to "patch" template YAML files are just plain bad: https://kubectl.docs.kubernetes.io/references/kustomize/kust...
The tiny examples might look kinda okay, but when someone has stacked 10 different patch operations in a single file, it gets a lot harder to keep track of what's going on.
You’re discouraged to nest your configs.
is it uglier? sure. but it's peace of mind...
in terms of config i'm using myself, say Kubernetes stuff, i really love YAML...because i know exactly what it's doing and i generally keep things simple. it's nice for that, it just does way too much IMHO...
If only Kubernetes hadn't gone and used it as the markup language of choice to represent... everything.
JSON lacks comments, that's the biggest differentiator in my opinion.
It also allows additional trailing , in lists. Something I hate but is a great feature if you use a macro system on top of it. (Like jinja2).
If you're sticking to certain variants, you may as well use YAML, which supports JSON notation, as well as comments and various other improvements.
I am not sure I may as well be using yaml. I don't like it for the multiple reasons in the OP and this thread.
If you are using python, I have found it to be quite easy to support both json5 and yaml, as well as converting between them for people who feel strongly about yaml. Not trivial but low effort.
- introduce the least idiomatic form of YAML as "depending on preference"
- add an optional preamble to the XML example
- add comments when there were none, but also not to all of them
If you didn't artificially stretch the different examples to match, there'd be a much clearer difference between them all, especially considering the fact one of your three examples is a superset of the other.
The odd one out can't even capture an integer vs a string without a schema.
But I think the point of adding comments was just to show that comments are possible in some formats, and not others. Omitting possible comments from the XML example might have just been a sign of fatigue over this topic ;)
At any rate, I find the (idiomatic) YAML example to be -- by far -- the most readable of all, including the GGP's TOML example.
- Most XML files I encounter come in this format. You can skip the preamble but it wouldn't match my real life experience.
- All readable config files I encounter have comments. I forgot to add comments to the XML representation, but I can't edit my comment anymore. I think everyone who ever encountered XML knows how to add comments, though. JSON simply doesn't support comments unless you use a niche JSON derivative.
As for the string versus integer problem: you always need a schema, or you'll run into very funny problems down the line. None of these formats intrinsically know what keys refer to an object and what keys refer to a string, that's all based on your schema anyway.
"10" is a string. 10 is a number. [10] is a single number in an array. {"number":10} is an object.
You're conflating advice for databases with advice for data serialization formats: XML captures less information about the data it contains intrinsically.
_
Also please don't use YAML as "JSON with comments", you're just asking to run into some obscure bug/corner case
If you're willing to do weird things there's always JSON5
This creates a serious footgun in Ubuntu netplan, leaving a server totally unbootable, but simultaneously not triggering "netplan try" as any sort of parsing problem:
https://news.ycombinator.com/item?id=37591110
String with ": " inside have to be quoted, that's correct, however you won't have space in your IPv6 address unless I miss something.
Getting in the habit of not doing so will lead to schema violations, like the Netplan problem you linked, which can crash the program trying to read your config. If it bails out at an unfortunate time, like most networking tools seem to do, you'll need to use a recovery boot image or serial console to fix your config.
Been there, done that. A good config file or linter should’ve complained and not allowed me to commit such misstake.
Lack of comments for JSON isn't a huge issue considering you can make the keys fairly verbose. And it would be actually pretty easy to add this into the spec, and parsers would still be backwards compatible.
I present jsonc: https://www.npmjs.com/package/jsonc
https://www.npmjs.com/package/json5
Making keys verbose tells you what a thing is, but comments are there to tell you why a thing is.
The only real way around this seems to be to create some kind of a "_comment" key.
Json but with comments and allowed commas on the end.
https://github.com/json5/json5
It's my preferred configuration file format, it fixes all the problems I have with JSON (trailing commas, comments) without turning it into a mess full of gotchas like YAML.
It’s without a spec
https://github.com/microsoft/vscode/issues/100688
https://github.com/microsoft/node-jsonc-parser
A theory - they don’t want a third party code in a hot path (they do care about performance in vscode), they already have a very performant parser and they don’t want to add a complexity there.
But that’s just a theory.
Lack of comments in JSON is a huge problem for config files. It's not an issue if you're just exchanging data between APIs, but for config files, comments are essentials.
There are some JSON specs that will do comments, but they rarely specify what dialects of JSON their parser accepts. There are also workarounds that abuse the fact duplicate key handling isn't part of the spec by specifying each key twice, once with a comment and once with data as most parsers only make the second key stick; those are even worse.
You can't add backwards compatible comments to JSON, there's no space in the JSON spec to retroactively insert comments somewhere. The closest you can do is the duplicate key trick, but as the spec doesn't state which of the keys to read as a value, that trick only works with specific parser implementations.
You can easily add comments to JSON spec, by just writing every parser going forward with the added comment parsing. It would read old JSON non commented files just fine.
None of them handles it well. YAML has 7 different modes to do it so you will inevitable mix up and use the wrong one, otherwise it's actually the only option that supports it. Json requires inlining \n. Xml only does it with whitespace indentation.
I just don't like TOML. Just rubs me the wrong way for some reason. Don't know why.
in short: all these have their use-cases. i use YAML where it fits and TOML where it fits better. I never use JSON because JSON is just for machines, I generate JSONs.
From the article:
> “I’m making a new kind of book, and I need to annotate all of the verses in the Bible, and have the chapter headings and stuff.”
XML is a markup language, and works great for marking up text. It came out of SGML and attempts to make machine-usable documentation.
I'd favour its use in something like a datasheet, which is a combination of human-readable information, nested objects, and lots of stuff that needs to be machine parseable in fairly precise ways.
IMO it also works "fine" for other structured document formats that aren't text, like SVG, but that's not a strong opinion. JSON and other formats compete more sensibly here, but I'd never want a protobuf-based format for... writing an essay, for example.
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.
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.
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.
- 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.
My motivation is expressing docker-compose.yaml in the "best" way I can imagine, as a design exercise. In that case, I'd rather have a bunch of (service ...) forms, instead of a "services" object. Not sure why. Maybe it's a pun on interpreter-driven formats like that used by [guix][1].
[1]: https://guix.gnu.org/manual/en/html_node/Shepherd-Services.h...
Haha, what?
I don't know what I'd prefer, exactly. Probably JSON, or better yet JSON5.
Then I used k8s for the first time. And after that, I understood, because k8s manifests are an abomination. Super error prone and hard to read. And I think that this has a whole lot more to do with the data model than the markup format. YAML isn't perfect (in particular, the way you specify an array of dicts is hot garbage and confusing), but it's not the main problem. The way the data is laid out in k8s would be awful to work with in any format.
YAML spaghetti is so much worse than dealing with XML tags, no tooling, no schema validation,...
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.
> “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:
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.The issue is not isolated to JS either, the same could have happened in python, php, or any other untyped language.
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.
No, this is a YAML problem, because YAML is specified to allow for unquoted strings, and then it uses heuristics to decide if you meant a string or a number or (god forbid) a boolean.
So the "code that accepts..." that you're talking about is literally every conforming YAML parser out there. And they do that because the spec tells them to. So yes, it is a YAML problem.
And to top that off, most of the examples and tutorials you'll find on how to use YAML don't quote their strings. I get the idea: fewer characters to type, more human readable. But god it's a minefield.
I do agree that TOML is a better option. Easy to write and easy to read.
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.
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/
In YAML it's kinda more baked in. You have anchors and alias, which are part of the spec itself.
Yeah, in retrospect Billion Laughs was a bit of a cheap shot. It is, however, hilarious. And no one ever put forward any sort of mitigation or fix, for decades[1]. Meanwhile, in the YAML dev world open issues . .
I don't really have a dog in the YAML fight - apart from Asciidoctor-pdf template files[1] - but the YML people are patching, and the XML people didn't, for a very long time.Why is that? I'm going to go back to the basic notion of XML as the Everything for Everything, which was encouraged by its design pattern insistence on fake semantics. YML has, no doubt, a big ol' dose of the same sickness, but with a lot less overhead, and it makes maintenance easier.
Keep in mind, we're now debating "How YML is perhaps just as bad as XML"
[1] This has resulted in a lot of software and IETM files (even whole devices) getting pulled from USN vessels in theatre; there's more than a few vulnerabilities that ride on the SGML/DTD Billion Laughs. Bunch of other ancient file formats getting the same treatment, something we in the industry saw coming since 2007. Just a ticking bomb until you fight a peer.
Then enjoy your complimentary security vulnerabilities.
Jokes aside what is it used for that XML Schema or other XML technologies can't do better?
USAF hasn't yet gotten nailed with the DTD attacks the way the USN was[0]. And that was a complete musterfluck. First they pulled all the handheld maintenance devices, then they basically mandated that all the stuff getting stuffed into entities could instead get shoved into a black box XML element stuffed full of Base64 or reference to an external binary or - hell - whatever you want. That's the current solution: the //multimedia element.
You'd think USAAF and USAA[1] would have learned something from this . .
[0] That's changing as we speak; DIA has a bunch of hardass new IT policies rolling out. God be praised.
[1] Although the USAA spec has more flex in it when it comes to geometry and other extremely specific rendering behaviors. It's much easier to optimize because it's not insistent that a frickin PDF parts catalog have draftsman-perfect line art.
Here's what the entities (specifically, CGM, the 800 lb gorilla of external entity references) do that can't be done in XML+SVG: ISO/IEC CGM:1999 line types (your dashed lines are exactly right); ISO/IEC CGM:1999 nurbs (so that the curves are just right). I have a bunch of counterarguments to these things and more, but the easiest one is : how much is a perfect dashed line worth? Is it worth twenty two million dollars? Because that's what it cost the Navy. That's assuming the PLAAF/PLAN doesn't hop inside your maintenance network off the east coast of Taiwan. Then you can buy your dashes at the reasonable cost of a few hundred dead sailors.
They need to swap out //multimedia for a standardized, text-based format yesterday, though. Either that or release an ISO profile for SVG, which honestly would be, like, a week's worth of work at most . . if you wanted to see it done, of course. Oh ISO Technical Steering, you and your loveable scamps made up almost entirely of stoneage software industry reps.
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.
I recall (perhaps inaccurately) seeing that notion somewhere in 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.
Yes, it is. If you design a format in such a way that type parsing is ambiguous, or in this case "keep trying to parse it over and over, starting with the most restrictive option and working your way down", people are going to commit errors. That's just life.
I would absolutely love it if YAML parsers supported a mode where quoting your strings was required. Or, while I'm wishing: a new YAML version that requires that (even though that's impossible to do backward-compatibly without yucky things like having to specify the YAML version in the document itself).
But I do still use YAML for config files, because there's enough about the other options that I don't like even more than YAML.
For a similar spec that offers no types outside of string, list, and dict, there's NestedText.
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.
The parser should have picked this mistake up, and the server shouldn't have been crippled to the extent of needing a rescue.
More docs seen here: https://netplan.readthedocs.io/en/latest/netplan-yaml/
Perhaps the trap is the complacency that YAML induces by not requiring quotes around keys/values, and so text risks being interpreted in unexpected ways. The infamous Norway Problem has the same root cause.
This is incorrect. The colon needs to be followed by whitespace for it to indicate a key-value pair. You can check this with the reference parser (and a bunch of others!) online: https://play.yaml.io/main/parser?input=YWxsb3dlZC1pcHM6IFswL...
I bet the parser did actually fail, because you can't parse a misformed dictionary into a string. Your problem is that the tool probanlt took down the interface before trying to parse for format, and then failed to bring the interface back up.
Similar to bogus data in /etc/network/interfaces, resetting the network interfaces with bogus data will end up with your server having no or limited connectivity capabilities.
At least with YAML there are command line parsers available to check your work. Plaintext config files often end up being a game or chance to see if you've got the format right.
I'm not convinced they'd define a sane schema for either.
Like you've noticed... the trying logic is naive. IIRC if this passes the mild sniff test it will go ahead and apply.
It can't realize changes on specific/named interfaces -- it insists on all or nothing.
As above, you can’t ask netplan to sanity check a config.
You can’t create a draft configuration, apply it, and save it if it works well. Every self-respecting network config system since at least Cisco IOS can do this (and does it by default!).
Interface renaming can’t filter by being a physical interface, which means that the system tries, and fails, to rename VLANs, because their MAC matches something that should be renamed. (networkd can handle this, but the networkd config written by netplan is wrong.)
Deleting virtual interfaces (e.g. VLANs) seems to be essentially unsupported, at least on 20.04. I think it’s slightly, but only slightly, better in newer releases.
Not impressed.
I've grown to enjoy NetworkManager. I know, like all things, that is probably controversial to some.
Two things I really appreciate about it:
I was surprised/frustrated with networkd initially, but enjoy it now.It getting involved with packet forwarding was an unwanted surprise during a modernization effort.
As soon as Windows/MacOS/Android/iOS clients want in on the fun, alas, you'll need something more complicated than innernet to accommodate these other clients.