> we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.

Using JSON for configuration is just the whole situation of using XML for data exchange redux. One of the major points for JSON over XML for data exchange was that it was so much better because it was optimized for data, not markup. Why are we ignoring this argument now that JSON is on the other side? JSON is used for configuration because it's ubiquitous, not because it fits the problem domain well. Let's just choose a more appropriate format.

Choosing the most common set of rules for INI files (what is proposed by Wikipedia[1] is probably sufficient) would serve us MUCH better than coaxing a data interchange format into that role.

1: https://en.wikipedia.org/wiki/INI_file

If you're using a strongly typed language, XML even has one (IMO) massive advantage over JSON: You can use XSD to define a schema declaratively. This means you get

(1) lots of general tooling support, in particular you get at least decent editor support for your config file, and

(2) you can autogenerate the code needed to read your configuration into structured data without having to do any unnecessary duplication of "key names" (tags) as you have to with e.g. INI or JSON. You also get the data sturctures themselves for "free" (based on the XSD).

Alright, it's not the end of the world to not have these things, but they're both very nice to have.

have you seen http://json-schema.org ?

Yes indeed I have, and I have several problems with it, one of which is "Expires: August 3, 2013" with no new version in sight. My other major problem is that AFAICT it doesn't support one of my pet favorite features namely "Algebraic Data Types"[0, 1]. If you extend json-schema like Swagger has done it might support ADTs properly AFAICT, but I don't have any actual practical experience with Swagger.

[0] https://en.wikipedia.org/wiki/Algebraic_data_type [1] I should note that support for ADTs in XSD is sometimes sketchy in the various code generators, but at least the XSD specification supports it. (It could also be argued that XSD supports something even more general... which it probably shouldn't since ADTs basically cover the whole data structure space unless you go to higher kinds, inheritance and such.)

well basically virtually anything other than JSON that's actually designed to be configuration would be better for configuration. There's dozens of them. that is the problem: JSON parsers and generators are ubiquitous in the way that no single configuration format is. Right now, I can just use json in any language and get data between any language and any other language. If I use it for config I get the advantage of even being able to config across multiple languages that might be getting used in a single system if I have to. No proper configuration format has that level of mindshare and interoperation.

Something like edn[1] perhaps? Worked really well in my projects.

[1]: https://github.com/edn-format/edn