Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am confused, when was YAML ever considered a superset of JSON?

These are completely different serialization formats.



By many people, e.g https://learning.sap.com/learning-journeys/build-side-by-sid...

But the yaml docs said it’s accidental

https://yaml.org/spec/1.2.2/

«The YAML 1.18 specification was published in 2005. Around this time, the developers became aware of JSON9. By sheer coincidence, JSON was almost a complete subset of YAML (both syntactically and semantically).»


Thanks. Didn't realize anyone thought this. I checked the YAML docs when I saw this post, and it didn't seem like an official feature.

The SAP article definitely states it, that's the first time I have seen it described that way.


I’ve seen the claim around, and I actually believed it, to be honest. I found that article by googling. I guess it’s still true enough for many cases.


I don't remember if it was an official talking point, but "you can load json on a yaml parser and it'll read the same" is a claim I've seen around.


The YAML 1.2 spec states:

> YAML can therefore be viewed as a natural superset of JSON, offering improved human readability and a more complete information model.


The YAML 1.0 spec says no such thing, it doesn't even mention JSON. Neither does the YAML 1.1 spec. The YAML 1.2.0 and 1.2.1 specs do say exactly that. 1.2.2 no longer does, but it reiterates that the primary focus of YAML 1.2 was to make it a strict superset of JSON.


You're right. I must have clicked the wrong link, the YAML 1.0 spec doesn't mention JSON. The quote was from 1.2, thanks for pointing that out!


However this wasn't really true till 1.2 if I am reading the spec correctly. Plus many parsers default to 1.1. =\


I wrote a similar article two years ago, with some screenshots of people claiming YAML is a superset of JSON: https://john-millikin.com/json-is-not-a-yaml-subset

It's one of those beliefs that seems like it should be true, but isn't for obscure technical reasons.


Your post's remark about YAML 1.2 being opt-in with a "%YAML 1.2" directive is true for the parser you are using (LibYAML), but is not compliant with the 1.2 spec. The spec specifies it should assume 1.2 and 1.1 should be opt-in.


It's true for all of the parsers that I tested at the time, which covered a couple different languages (Ruby, Python, C, Haskell).

It appears to still be true in at least Ruby and Python, which are probably the two most popular languages to write YAML-consuming programs in:

  $ irb -v
  irb 1.3.5 (2021-04-03)
  $ irb
  irb(main):001:0> require 'yaml'
  => true
  irb(main):002:0> YAML.load '{"a": 1e2}'
  => {"a"=>"1e2"}
  irb(main):003:0> 
and

  $ python3
  Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import yaml
  >>> yaml.safe_load('{"a": 1e2}')
  {'a': '1e2'}
  >>> 
--

  > The spec specifies it should assume 1.2 and 1.1 should be opt-in.
The spec for 1.2 says that, but that's the reason parsers can't upgrade to 1.2, because changing the default version will cause backwards-incompatible parsing changes. Without the version directive there's no way for the parser to know which version was intended, so it defaults to 1.1, so people writing YAML will write YAML 1.1 documents, because that's what the parsers expect.

The only way YAML 1.2 is going to displace older versions is in a greenfield ecosystem that has all its tools using YAML 1.2 from the beginning, but that requires an author who both (1) cares a lot about parser correctness, and (2) wants to use YAML as a config syntax, which isn't a large population.


It is indeed true for LibYAML, which is used by Python, Ruby, and the Haskell yaml package. The majority of YAML implementations I've seen that aren't based on LibYAML implement 1.2. I'm pointing it out because it's highly implementation dependent.


Not only does the spec say that, but it was an explicit goal of Ingy döt Net, the designer of YAML.


Official YAML spec says so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: