Even if my data looks like a document, I refuse to use XML. It's just too clumsy to traverse compared to JSON.
The advantage of a schema is you can validate your data and move to static typing in only a few lines of code. It's for this reason that I think the best option these days is to just use something like protobufs v3, which has a stable JSON serialization and a sensible schema specification.
But even for objecty data, rather than "documents", XML doesn't have to be clumsy. Checkout the code samples here for C++
Although stringly-typed XPath has the same problems as SQL, building complex queries through string concatenation. This is where JSON shines, because you usually just convert to a tree of your language's native data structures in one line and use your languages native facilities to traverse it from there.
object.listOfItems .reduce((item) => item.type === 'car') .map((item) => item.name));
This is way more powerful than xpath.
[0] https://en.wikipedia.org/wiki/YAML [1] https://en.wikipedia.org/wiki/INI_file
If you do not care too much about exchanging data with other apps then parser/generator supporting javascript style comments (e.g. json-cpp) would work. With each JSON value it can store "commentBefore" and "commentAfter". If you need you can strip these comments any time by parse + write cycle with "collectComments" option inactive.
And I find the whole "run minifiy/strip first" to be a hilarious suggestion from Douglas Crockford. It can be rephrased as "If you want comments in JSON, for a config file say, then don't use JSON."
That, and XML requiring the tag name in the closing tag, are some of the obvious, silly, mistakes. XML in particular. Without the named closing tags, just using, say, <>, would reduce the apparent bloat and annoyance by a very large factor.
The really good thing about XML, that it - unlike JSON - is extensible.
And traversing both JSON and XML (without the weird parts) are no-brainers. Every (or about so) mainstream language has libraries that make either format really transparent to use.
That's really only true about XML, that is not the case with JSON. JSON is a pain to work with in C# for example compared to XML.
I did some toy project in C# and haven't found handling JSON any painful. Maybe I just haven't hit the bad cases, though.
I don't exactly remember what I've used and what I wrote, but I think I had just installed some library (IIRC it was Json.NET), put some annotations on classes, and got my serialization. For deserialization I didn't wanted to write throwaway classes so I just made a JSONPath query and iterated over the result objects, looking at necessary properties. Nothing particularly different from how things are in, say, Python, except maybe for some extra type checking.
i refuse to use XML just like everyone else, but not because it's hard to parse data from.