Google put forward KYAML recently (https://www.kubernetes.dev/resources/keps/5295/), it looks like a more sane way forward.
JSON is naive, lacks almost everything. But is supereasy to parse and read.
As funny as it sounds, XML is overspecified. Parsing is possible and predictable but supporting the full standard (all of them) is so much work that nobody does it anyway.
So, given the choice above, i'd go for naive simplicity.
And then you have whatever the hell OpenAPI uses.
XML just looks nasty, but IMO not worse than JSON. JSON is not easy to read, because brackets suck for deep nesting. XML nesting is 100x easier to read, because the closing tags tell you exactly what is closing.
In xml's they clearly overdid it. all the formats/substandards you listed... there is just not a single library that supports all of the standard.
And because implementations are so different, most users just stick to a single C library. That library, btw, is also incomplete and undermaintained.
So that's the problem with complex standards: they are hard to implement and support. Nobody does this, unless it is a business-critical matter.
The lack of comments in JSON is not a bug; comments in JSON were an anti-feature. Douglas Crockford intentionally removed them to prevent developers from using comments to store parsing directives (which he saw people doing in earlier revisions).
* https://web.archive.org/web/20120507093915/https://plus.goog...
Even Douglas Crockford suggested that people could still use comments, as long as they strip them out before parsing.
Either you have an infinite spec, or you always have things outside it.
[0] YAML would allows you to tag the type, but nobody does it anyway
There are things like https://www.baeldung.com/jackson-streaming-api but maybe there's more in you definition of "streamable" that JSON doesn't satisfy.
So surely if YAML is streamable, JSON must be too?
Or are the YAML maintainers incorrect?
The json spec just doesnt do anything like that but jsonl does.
The first two formats I've implemented as fully streaming, the serializers emit into an output iterator one character/byte at a time and the deserializers only need to hold one value at a time (mostly for strings, and not even for CBOR's byte arrays, which are streamed). BSON requires full document instantiation because of byte offsets and is genuinely anti-streaming in its design.
I happen to have implemented a serializer for YAML, fully streaming, mostly as a compact-ish human-readable debug data representation. I can scarcely think of fates worse than having to write a spec-compliant YAML parser.
Given YAML is not a subset, but a superset of JSON, as you correctly noted, I'm not sure how you reached that conclusion.
> Or are the YAML maintainers incorrect?
I think you should check this page before making snarky comments: https://en.wikipedia.org/wiki/Superset
See also the comment below: https://news.ycombinator.com/item?id=49476489
Offtopic note: I wanted to dig the wiki superset link up the lazy way, so searched for superset, and all I got was endless list of marketing trash links. Even on DDG. RIP, we are on the Dead Internet.
Given: - YAML support streaming - any JSON is valid YAML
Conclusion - any JSON is streaming
The "streamed JSON" needs --- line sparators, which is not a JSON spec feature, thus that data stream is valid YAML from that point, bot not a valid JSON stream.
NDJSON is a different beast.
See Examples section.
How was my comment snarky? The YAML maintainers may have intended YAML to be a superset of JSON, but failed by not incorporating some obscure feature of it that bore on whether it was streamable or not.
I agree that Norway is better than YAML. Let's keep Norway and dump YAML.
> There is no problem with YAML
I am reminded of: "There are no American infidels in Baghdad. Never!"