3 ms·

At least JSON has a complete and unambiguous specification. If JSON had comments, we wouldn't need YAML 99% of the time.

rf15 3y ago
We actually offer both for configuration files of our software - YAML can be very pleasant to write and read for small datasets or those without much depth, without the overhead of curly brackets and quotation marks on everything. The original problem these formats solve is that people just want a simple nestable key-value structure/format, and both deliver on it - unlike xml. (when do you use an attribute vs a tag and text element?)
- kaba0 3y ago
  > when do you use an attribute vs a tag and text element When the schema says so — you even get auto-complete for that in any half-decent editor.
  - rf15 3y ago
    I know the history of xml, but just to get back to my original premise: why has a tag (a kind of key in the mind of most readers) multiple "kinds" of values/children in parallel, especially one set that is map-shaped (attributes) while the other is array-shaped (proper children)?
shaftway 3y ago
And trailing comments?
- dharmab 3y ago
  Nice to have, but an autoformatter can fix them up if you make a mistake.
Smaug123 3y ago
Not quite unambiguous! It declares how to parse numbers, but of course the "reference implementation" of JSON (insofar as there is one) is Javascript, in which numbers are floats and hence e.g. are bounded in precision, so the spec actually disagrees with the reference implementation.
- stkdump 3y ago
  I don't think this is true. The original specification (ECMA 404) only covers the formal language, i.e. what are valid documents and not what their memory representation after deserialisation is. A parser that rejects a number because it has too many digits would not be conforming. rfc8259 is more detailed and it mentions that most parsers will have limited precision and references ieee754 to explain what the expected precision after deserialisation should be for most parsers.
jiggawatts 3y ago
Parsing JSON is a minefield: http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html Its spec is not "complete and unambiguous"!

rf15 3y ago

We actually offer both for configuration files of our software - YAML can be very pleasant to write and read for small datasets or those without much depth, without the overhead of curly brackets and quotation marks on everything. The original problem these formats solve is that people just want a simple nestable key-value structure/format, and both deliver on it - unlike xml. (when do you use an attribute vs a tag and text element?)

kaba0 3y ago
> when do you use an attribute vs a tag and text element When the schema says so — you even get auto-complete for that in any half-decent editor.
- rf15 3y ago
  I know the history of xml, but just to get back to my original premise: why has a tag (a kind of key in the mind of most readers) multiple "kinds" of values/children in parallel, especially one set that is map-shaped (attributes) while the other is array-shaped (proper children)?

shaftway 3y ago

And trailing comments?

dharmab 3y ago
Nice to have, but an autoformatter can fix them up if you make a mistake.

Smaug123 3y ago

Not quite unambiguous! It declares how to parse numbers, but of course the "reference implementation" of JSON (insofar as there is one) is Javascript, in which numbers are floats and hence e.g. are bounded in precision, so the spec actually disagrees with the reference implementation.

stkdump 3y ago
I don't think this is true. The original specification (ECMA 404) only covers the formal language, i.e. what are valid documents and not what their memory representation after deserialisation is. A parser that rejects a number because it has too many digits would not be conforming. rfc8259 is more detailed and it mentions that most parsers will have limited precision and references ieee754 to explain what the expected precision after deserialisation should be for most parsers.

jiggawatts 3y ago

Parsing JSON is a minefield: http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html Its spec is not "complete and unambiguous"!