I disagree. TOML is terrible at handling nested data.

Check this thread:

https://news.ycombinator.com/item?id=17523194

I don't see Kubernetes switching to TOML anytime soon!

There may be no nested data in his use case. There’s no single correct answer here.

Too YAGNI for me.

I have nesting up to three levels deep. I use inline tables^ for the many innermost (or other few-element) tables. It's never seemed excessively verbose.

^https://toml.io/en/v1.0.0#inline-table

A bit later you see [fruits.physical]

Even XML doesn't make you repeat the higher level keys!

Also agree, I find toml way less readable than yaml for lots of data structures

I feel like if you have data so nested that TOML is a problem then your schema is a problem/you should just be using a script

I think the "right" choice is HCL

It's plenty easy to convert YAML to JSON and use it in Terraform :)

https://www.terraform.io/docs/language/syntax/json.html

Why convert when HCL is superior to YAML and JSON?

It isn't. YAML and JSON are much more proven than HCL. HCL is used for some relatively small products. Just making something more complicated doesn't make it better.

Proven in what sense? Several implementations are broken are incorrect. HCL is used in very large products as well. Just because it isn't the majority currently doesn't mean that it isn't a worthy choice. HCL isn't more complicated if used as an alternative to YAML or JSON, in fact, I would argue that it is simpler. It bridges the pros of YAML and JSON combined, and addresses the nested complexity of TOML. It really is IMO the best, but you of course are free to share a different opinion. However, I would encourage you to actually try it out and re-evaluate.

The unreadability of XML is grossly exaggerated.

I agree. I have never really had a problem reading XML myself.

There’s properties files too, but TOML is my “format of choice” as well for a bunch of use-cases where human readability is important.

More people should give it a try. Very reminiscent of old Windows INI files and Java properties.

TOML is pretty good but it gets too verbose when you add bunch of arrays.

All we need is to revise official JSON standard(ECMA 404) to include comments.

And trailing commas. And unquoted keys.

Why are unquoted keys so critical? I feel like one of the strengths of a DDL like JSON or XML is that it's easy to tell what the data (key-value pair or otherwise) is, while with YAML and others, understanding data-vs-structure can be challenging.

Mostly so copy between JS and JSON isn’t such a PITA.

It’s not essential, but if we’re already changing the format we might as well?

> All we need is to revise official JSON standard(ECMA 404) to include comments.

That would be a step back for GitLab CI, GitHub Actions, Kubernetes, Google App Engine, and a bunch of other projects which use YAML and seldom encounter the Norway problem. https://hitchdev.com/strictyaml/why/implicit-typing-removed/

That's fine. They should not have used a format made for data to describe what essentially is code.

Why shouldn't they have?

TOML can't decide if it's a super INI file or a JSON cousin. You can represent the same information using two completely different representations and you can mix both styles in the same document. Manually navigating and editing values is error prone and hard to automate.

JSON with comments would be ideal.

Which is why many parsers support that. I'm positive you'll find one that does so in pretty much every environment.

In that case, you might want to have a look at JSON5: https://json5.org/

It is pretty niche, but attempts to improve upon JSON in a multitude of ways, one of which is the support for comments: https://spec.json5.org/#comments

The libconfig format is fairly close to that, and it's great!

http://hyperrealm.github.io/libconfig/libconfig_manual.html#...

I guess it's just matter of personal taste, but I don't see how XML is any more "unreadable" than any of the other options mention here.

TOML can handle nested data at the application level by using entity reference token semantics.

It does need an XPath traversal and search query format for application use and data references.

Shoehorning.