Possible improvements occur to me:<p>1. If indentation is significant and required, dotted notation should be optional:<p><pre><code> [foo]
[bar]
[car]
</code></pre>
The parser should be able to understand that this results in a foo.bar.car structure without explicitly using dotted notation in the keys.<p>2. Support include files. With #1 implemented, includes would be extremely powerful and flexible. Since indentation is required, no special syntax is needed to relatively position the included files. And without requiring dotted notation in keys, include files can be reused in a configuration (such as common settings in the [servers] section of the example).
I don't know if this is the answer, but I'm a fan of someone trying.<p>I personally never jumped on YAML or JSON. I liked that they weren't XML, but they each felt like XML++ too much for me. There was still too much, I don't know, weirdness/typing/oops! Don't get me wrong, I think they were better than XML, but only marginally. It would be nice to see more of a phase change type of approach. I'd LOVE to see something like this (or something else) that involves much less typing/special characters/etc than YAML and JSON.<p>Personal opinion.
The format could be very simple, but... allowing comments after values make it unnecessarily complex to parse. For example:<p><pre><code> value = "example # no that's not a comment" # but here's one
</code></pre>
If inline comments where not allowed we could just check the first and last character for a quote and we know we have a string, same for arrays (check for [ and ]). But with inline comments, we need to parse the whole string.<p>As far as I can see both the C# and Python parsers don't handle this kind of comment correctly at the moment, and probably many implementations will have troubles with that. They should just drop this option in my opinion.
So the objection to JSON comes down to a couple of things: no comments and fragility in face of a trailing comma. I wonder if the right thing though would be to fix JSON (maybe even call it something else) rather than throw the baby out with the bathwater.<p>Personally, of course, I think we should just use a slightly modified version of s-exprs which would be easier to parse.<p>(:keyword value)<p>where value can be an atom, list of atoms or a list of keyword value pairs. Comments could follow the Lisp convention and start with semi-colon and end with newline. Only 5 characters to escape, namely, '(', ')', ':', ' ' and ';'.
INI, JSON and YAML all have problems. None of them are serious enough for me to consider this for a small project with one or two config files required. Good to be able to point to a config file syntax done right though.