I think the core concept of using `<>`-delimited tags to group items is sound for config and similar human-writable files. I.e. XML-like markup. This means tha

I think the core concept of using `<>`-delimited tags to group items is sound for config and similar human-writable files. I.e. XML-like markup. This means that XML subsets are actually pretty decent. Basically the subset of: - `<!-- ... -->` comments - `<foo>...</foo>` and `<foo/>` tags - `>` and similar entities (basically, just the XML-builtin ones, no custom declarations) - optionally: `<?xml ... ?>` tag at the start (just for compatibility) - optionally: `<![CDATA[...]]>` (where required for the application) - optionally: `<foo:bar/>` namespaces (but without needing to declare them like in XML; essentially, just adding ':' as a permitted character) If I were to extend it, I'd probably also add HTML-like value-less parameters, like `<input readonly/>`. I'd also add an API to create custom entities (but no support within the file itself), to make it more adaptable to specific use-cases. And this is it. The big issue with XML is all the complexities of DTDs and being able to declare new entities, etc. It was also woefully overused at some point, in not-really-XML ways --- such as by XMPP (which would work much better as a binary protocol). --- I agree on YAML, by the way. It tries to do too much, and ends up being very unintuitive (here's one for you: what are the various ways of having a multiline string?). It doesn't help that two different parsers won't generally agree on all the details of the format. I think TOML (Tom's Obvious, Minimal Language) is a good compromise, if you're looking for something in a similar JSONy-but-human-writable vein.