3 ms·

> When dealing with large YAML files, I find myself frequently popping them into online “YAML to JSON” tools to actually figure out WTF is going on. YAML is a

> When dealing with large YAML files, I find myself frequently popping them into online “YAML to JSON” tools to actually figure out WTF is going on. YAML is a strict superset of JSON, so defining the former in the syntax of the latter is fully supported by the spec. Perhaps not by every YAML library, to be sure, but those which do not are not conformant. From the YAML spec[0]: The YAML 1.23 specification was published in 2009. Its primary focus was making YAML a strict superset of JSON. 0 - https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/

Centigonal 2y ago
I'm confused about your point about YAML being "strict superset of JSON" leading to being able to convert YAML to JSON. If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Wouldn't that make it impossible to define all YAML files as valid JSON?
- Dylan16807 2y ago
  They all turn into the same data types in the end. You can import a YAML and output a JSON. For a feature like references, you'd have to do the annoying thing and duplicate that section of the file. For a feature like unquoted strings or extra commas, you just quote the strings or remove the commas. The various YAML features are in between and mostly close to the latter.
- AdieuToLogic 2y ago
  > If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Yes. One of the features YAML supports is the widely documented format we are all familiar with. However, being a "strict superset of JSON" also means a conformant YAML implementation can load a "pure" JSON resource without issue. The converse is not generally possible as JSON cannot express what YAML can, such as octothorpe ('#') comments. HTH EDIT: see also https://news.ycombinator.com/context?id=42361994 https://news.ycombinator.com/context?id=42361994
yashap 2y ago
For sure, but most YAML you actually encounter does not use much in the way of JSON syntax, it looks a lot more like this: https://devblogs.microsoft.com/devops/wp-content/uploads/sites/6/2020/11/exported-yaml.png https://devblogs.microsoft.com/devops/wp-content/uploads/sit... Where arrays and objects just look too similar (IMO), white space is significant, most strings are unquoted, etc. And personally I find it quite difficult to really understand what’s going on there, at a glance, compared to JSON (or JSON5).
- dragonwriter 2y ago
  > For sure, but most YAML you actually encounter does not use JSON syntax So what? YAML can be trivially mechanically translated between flow and block syntax.
  - yashap 2y ago
    I want to be able to easily read and understand configuration without having to pop it into a converter. The YAML I encounter in the wild is ~80% pure block style, ~20% mixed (within a single file, mostly block style with some flow style). And I just find the block style hard to read, I have to either spend significant mental effort trying to understand where the objects vs. arrays are, or I have to pop it into a converter (to either JSON or flow style) to understand. Whereas JSON/JSON5, it’s immediately clear without any mental overhead.

Centigonal 2y ago

I'm confused about your point about YAML being "strict superset of JSON" leading to being able to convert YAML to JSON. If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Wouldn't that make it impossible to define all YAML files as valid JSON?

Dylan16807 2y ago
They all turn into the same data types in the end. You can import a YAML and output a JSON. For a feature like references, you'd have to do the annoying thing and duplicate that section of the file. For a feature like unquoted strings or extra commas, you just quote the strings or remove the commas. The various YAML features are in between and mostly close to the latter.
AdieuToLogic 2y ago
> If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Yes. One of the features YAML supports is the widely documented format we are all familiar with. However, being a "strict superset of JSON" also means a conformant YAML implementation can load a "pure" JSON resource without issue. The converse is not generally possible as JSON cannot express what YAML can, such as octothorpe ('#') comments. HTH EDIT: see also https://news.ycombinator.com/context?id=42361994 https://news.ycombinator.com/context?id=42361994

yashap 2y ago

For sure, but most YAML you actually encounter does not use much in the way of JSON syntax, it looks a lot more like this: https://devblogs.microsoft.com/devops/wp-content/uploads/sites/6/2020/11/exported-yaml.png https://devblogs.microsoft.com/devops/wp-content/uploads/sit... Where arrays and objects just look too similar (IMO), white space is significant, most strings are unquoted, etc. And personally I find it quite difficult to really understand what’s going on there, at a glance, compared to JSON (or JSON5).

dragonwriter 2y ago
> For sure, but most YAML you actually encounter does not use JSON syntax So what? YAML can be trivially mechanically translated between flow and block syntax.
- yashap 2y ago
  I want to be able to easily read and understand configuration without having to pop it into a converter. The YAML I encounter in the wild is ~80% pure block style, ~20% mixed (within a single file, mostly block style with some flow style). And I just find the block style hard to read, I have to either spend significant mental effort trying to understand where the objects vs. arrays are, or I have to pop it into a converter (to either JSON or flow style) to understand. Whereas JSON/JSON5, it’s immediately clear without any mental overhead.