9 ms·

As much as i would like to see comments in json: if we start throwing around json files that area not really json, but we call them json, (at least in everyday

by tudborg 13y ago

As much as i would like to see comments in json: if we start throwing around json files that area not really json, but we call them json, (at least in everyday talk), we will end up breaking more apps then we fix. Maybe the question is instead; why the hell do we need comments (and loosening of t he syntax, etc) in the first place? Are we seriously going to keep insisting on json as a configuration format? As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml. yaml have comments yaml makes it easy to enter multiline strings and most if all; yaml is very very easy to write! tl;dr: Just use a format suited for your needs instead of trying to change something that doesn't. Oh, and a couple of smiley faces thrown in there to ensure people don't read this in the wrong tone. People do that.. Like, all the time.. damn, now my tl;dr is too damn long! i have to add another. tl;dr;tl;dr YAML BITCHES! (╯°□°）╯︵ ┻━┻ (but also, a puppy: http://i.imgur.com/kuDsS0i.jpg http://i.imgur.com/kuDsS0i.jpg )

derefr 13y ago
If web browsers had native YAML parsing, we probably wouldn't need JSON5. Web browsers aren't going to get native YAML parsing.
- drdaeman 13y ago
  > Web browsers aren't going to get native YAML parsing. Because of what?
- stormbrew 13y ago
  They probably aren't going to get native json5 parsing either (except in the sense that you can do something stupid like eval it). That said, I don't think there's any particular need for yaml in the browser. Browser code is usually dealing with machine-generated data, where even normal json is just fine.
  - derefr 13y ago
    Rich client-side apps need configuration files too.
    - yeukhon 13y ago
      If this was merely a configuration (say for node.js) which sits on the server, then you probably just import a npm to read yaml (I don't write node.js so I don't know if using .yaml is feasible as node.js config file or not). So the use case is limited. I used to work on a project which users could edit a configuration file through a web editor and we chose YAML because writing JSON by hand is painful (I hate the comma error!). But we processed this YAML file for the user on the server side, so having a native YAML parser in browser and Javascript wouldn't really help me at all.
      - derefr 13y ago
        No, I'm talking about configuration files that get interpreted by code that is executing within the browser. For example, a configuration-data file format for specifying a "brush" in a JS-client paint program. That'd obviously be a schema on top of JSON, right? Well, now you've got all of JSON's inherent limitations.
        j03w 13y ago
        Then you don't need JSON, all you need is the plain old JS object.
        derefr 13y ago
        You're thinking of the live representation of the "model" of a brush in the program. I'm talking about the "definition" of a brush, from which the program loads that model. Another example would be, say, a "level" in an HTML5 game. These things ship alongside the game as blobs of data. Those blobs need a format that the browser can parse. Currently, JSON is that format, and it's inadequate for that.
  - novaleaf 13y ago
    don't need native json5 parsing. just load the lib up. the problem is yaml is there isn't any safe+browser version that I know of.
- deleted 13y ago
  [deleted]
malkia 13y ago
Whitespaces. These are the real killers.
X-Istence 13y ago
YAML is annoying, can't use tabs, you have to use spaces... and most yaml parses if they see a tab don't warn you or anything. Highly annoying for configuration files.
- coherentpony 13y ago
  > YAML is annoying, can't use tabs, you have to use spaces Are you serious? Would you put tabs in source code too? > and most yaml parses if they see a tab don't warn you or anything If they warned you, you still can't use tabs it's just that you're more aware that you can't use them. It's not entirely clear to me what your point is. Perhaps it's that tabs is your preference. Unfortunately, spaces are the preferred whitespace marker for 99% of programmers. Also, pulled directly from the YAML FAQ [1]: Why does YAML forbid tabs? Tabs have been outlawed since they are treated differently by different editors and tools. And since indentation is so critical to proper interpretation of YAML, this issue is just too tricky to even attempt. Indeed Guido van Rossum of Python has acknowledged that allowing TABs in Python source is a headache for many people and that were he to design Python again, he would forbid them. [1]: http://www.yaml.org/faq.html http://www.yaml.org/faq.html
  - stormbrew 13y ago
    I think you might overstate the percentage here, but I think the overall sentiment is true. But I've always thought a better approach would be to ban combining leading tabs with leading spaces at the file level and leaving the choice up to the user beyond that. I believe python3 actually takes this approach. But I am glad that YAML made any choice at all. Allowing mixing is absolutely the worst possible option.
    - GeneralMayhem 13y ago
      ahem http://www.emacswiki.org/SmartTabs http://www.emacswiki.org/SmartTabs
      - stormbrew 13y ago
alptrv 13y ago
I see this comment every time for many of years in almost every discussion about using JSON for configuration and while YAML is certainly used by many projects most of the people still continue to use JSON and I think that's because YAML sometimes feels like Scala of serialization markups when people just want something like Python. I personally think that TOML[0] is not only more simple but also as easy to read as YAML and we use it in our projects without any issues. 0. https://github.com/mojombo/toml https://github.com/mojombo/toml
- stormbrew 13y ago
  TOML is ok too, though I still like YAML better personally. I honestly didn't really like ini files much at any point, even when everything on windows used them, so TOML starts from an unhappy premise for me.
georgewfraser 13y ago
Json originally had comments, they were intentionally removed: https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04cipiaorjydfxg5tc0k https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04...
- swift 13y ago
  Crockford's explanation is pretty absurd, though.
  - balls187 13y ago
    How so? Also "Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." Seems like a perfectly fine way to have comments (if you absolutely need them) in a production environment.
    - DougBTX 13y ago
      Presumably JSMin removes optional quotes in object laterals, so it probably doesn't output valid JSON.
      - spellboots 13y ago
        That would be a pretty big mistake for the author of both the JSON spec and JSMin to make? Maybe it is but it seems unlikely.
        reverius42 13y ago
        JSMin is not the right tool for this. I'm sure it conforms to the JavaScript (ECMAScript) spec but probably not the JSON spec. Here's a trivial JavaScript function to convert JSON5 to regular JSON with no comments and quoted identifiers and all that good stuff: function JSON5_to_JSON(str) { return JSON5.parse(str).stringify(); } This is exactly what is suggested in the Usage section of the linked article.
wisty 13y ago
Or you can do this: config = { "version": "1.0", "comment": "JSON has comments too!" }
- jawngee 13y ago
  I hope you're joking.
  - kgabis 13y ago
    Why? It's a valid solution.
    - lowboy 13y ago
      Mixing metadata in with data isn't ideal.
      - yxhuvud 13y ago
        Mixing metadata with a serialization format isn't ideal. Want metadata? Use a markup language.
      - zimbatm 13y ago
        But metadata is also data.
      - coldtea 13y ago
        Actually it is. Then you can treat them the same way. And since it's a configuration format, you know what keys are accepted and what keys are for the metadata, and thus won't clash.
  - arunoda 13y ago
    this is what is recommended for package.json in node. Specially "//" as the key.
- mpyne 13y ago
  That's what we did for some of our KDE build infrastructure metadata, since there was no way I was using YAML if I could avoid it for something this simple.
comex 13y ago
YAML looks nice, but it's very overcomplicated for what it's usually used for [1]. Nobody wants to figure out what %TAG directives or "|", "|-", and "|+" at the end of lines mean, the difference between the folded style and the literal style, etc. just to read a configuration file. I don't like JSON either due to the comment issue; simple ad-hoc configuration formats like most C programs seem to have mostly work, but aren't as nice as a standard format. If anything, I like configuration files expressed as scripts in whatever language the program is written in, since they're very flexible (if I want 100 almost-identical entries for whatever reason, I can say so in the file rather than writing a separate generator), and while programming languages are complicated, people tend to already know them; but that does tie you to a specific language. [1] http://www.yaml.org/spec/1.2/spec.html http://www.yaml.org/spec/1.2/spec.html
- stormbrew 13y ago
  I think this is an entirely valid criticism of yaml. I'd absolutely support there being a simplified form of yaml (YAML The Good Parts?) that covers what people actually want to do and doesn't try to be a swiss army knife object serialization format.
  - Ygg2 13y ago
    Problem is people don't agree on Good Parts. People seem to think keeping YAML a superset of JSON is the good part. I'd think otherwise. Anyway, http://ogdl.org/ http://ogdl.org/ is one candidate for YTGP (YAML The good parts) but it's comments can carry metadata, which is a huge turn-off, others think TOML (https://github.com/mojombo/toml https://github.com/mojombo/toml) is a good replacement, but it has no support for alternate number types. You write in something like mask = 0xDEADBEEF into something like mask = 3735928559
    - philwelch 13y ago
      Ideally you would have a strict subset of YAML rather than a totally different language for compatibility reasons. You can call it the Friendly, Readable, Declarative YAML standard so we can have a standards war that is FRDY vs. JSON.
harshreality 13y ago
> As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml. Unfortunately YAML for untrusted input and data exchange is unsafe by default, depending on the language and implementation. A flag might need to be set, or extra modules included like SafeYAML[1] to keep Yaml from instantiating arbitrary objects. [1] https://github.com/dtao/safe_yaml https://github.com/dtao/safe_yaml
- crdoconnor 13y ago
  >The problem with YAML is it's not safe by default Why would that be an issue when using it as a configuration format?
  - coldtea 13y ago
    Because the parsers for that configuration format are unsafe too? Duh!
- rat87 13y ago
  I thought the problem wasn't with yaml but with allowing deserialize arbitrary objects which is unsafe by default for a format used both for 'trusted' and 'untrusted' input, If you have a json library which tries to allow deserializing arbitrary objects by default (with a load rather then unsafe_load method). Python's pickle serialization is unsafe but it warns you that its unsafe and is not widely used leading to it not being used as a serialization format for for unsafe input.
daGrevis 13y ago
We tried to use YAML at first, but problems with data types (can't correctly remember what, but there was no way to force something to be something) made us to rewrite our test fixtures to JSON. The only problem with JSON for us is that it doesn't support any comments, but JSON5 seems to fix it. There's a interesting format for configuration called TOML[1], you should check it out! [1] https://github.com/mojombo/toml https://github.com/mojombo/toml
coldtea 13y ago
>Are we seriously going to keep insisting on json as a configuration format? Yes. It has good universal support, often without needing any libraries, it's simple, succint, and has good tooling. >As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml. Let's just not go there. YAML is a pain in the ass to parse, has different incompatible versions, the libraries are of widely varying quality, is not natively (without third party stuff) supported in most languages, and it's generally a mess.
- clarkevans 13y ago
  There are lots of problems with YAML; it does too much. If I had time, I'd definitely want to do a 2.0 that gives it a small haircut removing the most bothersome of problems. I've been unable find time for work required: about a year of discussing, writing, coding, testing, packaging, and forging consensus. What I'd keep in YAML is the information model. When we started YAML ~12 years ago, it was obvious that configuration should be in XML, and that XML's information model was the correct way to organize data structures. Part of YAML's work was explaining a different way of doing things to those who'd otherwise use XML. This isn't a concern these days... That said, the productions look painful because the specification doesn't separate the scanner from the parser. Once you do that, the syntax is quite a bit more sane to grok (see PyYAML source). It's not nearly as bad as what you may think... IF you see it this way. Besides a few unfortunate syntax structures, YAML's complexity and sharp edges comes from it's venture into typed objects, type-spaces, and implicit typing. Much of this, for configuration files, is unnecessary. When we wrote YAML, we only had a few years experience with it; and well, it wasn't done as a full time endeavour. It was a guess as to how things should work. It wasn't easy to bootstrap YAML. It's now ten years later... and, well, lots of people have experience with it. It's probably time for the haircut.
  - jrochkind1 13y ago
    oh, please do this. I love yaml -- except on the rare by very painful occasions where I get hugely bitten by incredibly weird problems arising from unexpected interplay of yaml features. Some of the originators of yaml are probably the only people who the social power to promulgate a revision with a haircut. That would be awesome.
SixSigma 13y ago
s-expressions
SimHacker 13y ago
YAML failed the intelligence test of getting its name right in the first place: "Yet Another Markup Language". YAML is NOT a markup language, in any way shape or form, yet the people who designed and named it earnestly thought they were designing a markup language, and that there was a need for yet another one. Only when somebody pointed out that obvious fact to them, did they come up with a recursive retronym to paper over their initial stupidity: "YAML Ain't Markup Language". How clever by half. I prefer to use formats that were designed by people who actually knew what they were doing and what it was called and how it was meant to be used.
kazagistar 13y ago
JSON Schema has a ton of implementations and tools hanging off of it. It is possible to load and validate a config, and then display a reasonably nice UI for editing it (in such a way that the resulting state is also valid), all by creating a single declarative JSON Schema. Nothing comparable exists for YAML as far as I can tell, and by virtue of its complexity, it is unlikely to exist for quite some time.

by tudborg 13y ago

derefr 13y ago

If web browsers had native YAML parsing, we probably wouldn't need JSON5. Web browsers aren't going to get native YAML parsing.

drdaeman 13y ago
> Web browsers aren't going to get native YAML parsing. Because of what?
stormbrew 13y ago
They probably aren't going to get native json5 parsing either (except in the sense that you can do something stupid like eval it). That said, I don't think there's any particular need for yaml in the browser. Browser code is usually dealing with machine-generated data, where even normal json is just fine.
- derefr 13y ago
  Rich client-side apps need configuration files too.
  - yeukhon 13y ago
    If this was merely a configuration (say for node.js) which sits on the server, then you probably just import a npm to read yaml (I don't write node.js so I don't know if using .yaml is feasible as node.js config file or not). So the use case is limited. I used to work on a project which users could edit a configuration file through a web editor and we chose YAML because writing JSON by hand is painful (I hate the comma error!). But we processed this YAML file for the user on the server side, so having a native YAML parser in browser and Javascript wouldn't really help me at all.
    - derefr 13y ago
      No, I'm talking about configuration files that get interpreted by code that is executing within the browser. For example, a configuration-data file format for specifying a "brush" in a JS-client paint program. That'd obviously be a schema on top of JSON, right? Well, now you've got all of JSON's inherent limitations.
      - j03w 13y ago
        Then you don't need JSON, all you need is the plain old JS object.
        derefr 13y ago
        You're thinking of the live representation of the "model" of a brush in the program. I'm talking about the "definition" of a brush, from which the program loads that model. Another example would be, say, a "level" in an HTML5 game. These things ship alongside the game as blobs of data. Those blobs need a format that the browser can parse. Currently, JSON is that format, and it's inadequate for that.
- novaleaf 13y ago
  don't need native json5 parsing. just load the lib up. the problem is yaml is there isn't any safe+browser version that I know of.
deleted 13y ago
[deleted]

malkia 13y ago

Whitespaces. These are the real killers.

X-Istence 13y ago

YAML is annoying, can't use tabs, you have to use spaces... and most yaml parses if they see a tab don't warn you or anything. Highly annoying for configuration files.

coherentpony 13y ago
> YAML is annoying, can't use tabs, you have to use spaces Are you serious? Would you put tabs in source code too? > and most yaml parses if they see a tab don't warn you or anything If they warned you, you still can't use tabs it's just that you're more aware that you can't use them. It's not entirely clear to me what your point is. Perhaps it's that tabs is your preference. Unfortunately, spaces are the preferred whitespace marker for 99% of programmers. Also, pulled directly from the YAML FAQ [1]: Why does YAML forbid tabs? Tabs have been outlawed since they are treated differently by different editors and tools. And since indentation is so critical to proper interpretation of YAML, this issue is just too tricky to even attempt. Indeed Guido van Rossum of Python has acknowledged that allowing TABs in Python source is a headache for many people and that were he to design Python again, he would forbid them. [1]: http://www.yaml.org/faq.html http://www.yaml.org/faq.html
- stormbrew 13y ago
  I think you might overstate the percentage here, but I think the overall sentiment is true. But I've always thought a better approach would be to ban combining leading tabs with leading spaces at the file level and leaving the choice up to the user beyond that. I believe python3 actually takes this approach. But I am glad that YAML made any choice at all. Allowing mixing is absolutely the worst possible option.
  - GeneralMayhem 13y ago
    ahem http://www.emacswiki.org/SmartTabs http://www.emacswiki.org/SmartTabs
    - stormbrew 13y ago

alptrv 13y ago

I see this comment every time for many of years in almost every discussion about using JSON for configuration and while YAML is certainly used by many projects most of the people still continue to use JSON and I think that's because YAML sometimes feels like Scala of serialization markups when people just want something like Python. I personally think that TOML[0] is not only more simple but also as easy to read as YAML and we use it in our projects without any issues. 0. https://github.com/mojombo/toml https://github.com/mojombo/toml

stormbrew 13y ago
TOML is ok too, though I still like YAML better personally. I honestly didn't really like ini files much at any point, even when everything on windows used them, so TOML starts from an unhappy premise for me.

georgewfraser 13y ago

Json originally had comments, they were intentionally removed: https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04cipiaorjydfxg5tc0k https://plus.google.com/app/basic/stream/z12ztpczbxrdglfgl04...

swift 13y ago
Crockford's explanation is pretty absurd, though.
- balls187 13y ago
  How so? Also "Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." Seems like a perfectly fine way to have comments (if you absolutely need them) in a production environment.
  - DougBTX 13y ago
    Presumably JSMin removes optional quotes in object laterals, so it probably doesn't output valid JSON.
    - spellboots 13y ago
      That would be a pretty big mistake for the author of both the JSON spec and JSMin to make? Maybe it is but it seems unlikely.
      - reverius42 13y ago
        JSMin is not the right tool for this. I'm sure it conforms to the JavaScript (ECMAScript) spec but probably not the JSON spec. Here's a trivial JavaScript function to convert JSON5 to regular JSON with no comments and quoted identifiers and all that good stuff: function JSON5_to_JSON(str) { return JSON5.parse(str).stringify(); } This is exactly what is suggested in the Usage section of the linked article.

wisty 13y ago

Or you can do this: config = { "version": "1.0", "comment": "JSON has comments too!" }

jawngee 13y ago
I hope you're joking.
- kgabis 13y ago
  Why? It's a valid solution.
  - lowboy 13y ago
    Mixing metadata in with data isn't ideal.
    - yxhuvud 13y ago
      Mixing metadata with a serialization format isn't ideal. Want metadata? Use a markup language.
    - zimbatm 13y ago
      But metadata is also data.
    - coldtea 13y ago
      Actually it is. Then you can treat them the same way. And since it's a configuration format, you know what keys are accepted and what keys are for the metadata, and thus won't clash.
- arunoda 13y ago
  this is what is recommended for package.json in node. Specially "//" as the key.
mpyne 13y ago
That's what we did for some of our KDE build infrastructure metadata, since there was no way I was using YAML if I could avoid it for something this simple.

comex 13y ago

YAML looks nice, but it's very overcomplicated for what it's usually used for [1]. Nobody wants to figure out what %TAG directives or "|", "|-", and "|+" at the end of lines mean, the difference between the folded style and the literal style, etc. just to read a configuration file. I don't like JSON either due to the comment issue; simple ad-hoc configuration formats like most C programs seem to have mostly work, but aren't as nice as a standard format. If anything, I like configuration files expressed as scripts in whatever language the program is written in, since they're very flexible (if I want 100 almost-identical entries for whatever reason, I can say so in the file rather than writing a separate generator), and while programming languages are complicated, people tend to already know them; but that does tie you to a specific language. [1] http://www.yaml.org/spec/1.2/spec.html http://www.yaml.org/spec/1.2/spec.html

stormbrew 13y ago
I think this is an entirely valid criticism of yaml. I'd absolutely support there being a simplified form of yaml (YAML The Good Parts?) that covers what people actually want to do and doesn't try to be a swiss army knife object serialization format.
- Ygg2 13y ago
  Problem is people don't agree on Good Parts. People seem to think keeping YAML a superset of JSON is the good part. I'd think otherwise. Anyway, http://ogdl.org/ http://ogdl.org/ is one candidate for YTGP (YAML The good parts) but it's comments can carry metadata, which is a huge turn-off, others think TOML (https://github.com/mojombo/toml https://github.com/mojombo/toml) is a good replacement, but it has no support for alternate number types. You write in something like mask = 0xDEADBEEF into something like mask = 3735928559
  - philwelch 13y ago
    Ideally you would have a strict subset of YAML rather than a totally different language for compatibility reasons. You can call it the Friendly, Readable, Declarative YAML standard so we can have a standards war that is FRDY vs. JSON.

harshreality 13y ago

> As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml. Unfortunately YAML for untrusted input and data exchange is unsafe by default, depending on the language and implementation. A flag might need to be set, or extra modules included like SafeYAML[1] to keep Yaml from instantiating arbitrary objects. [1] https://github.com/dtao/safe_yaml https://github.com/dtao/safe_yaml

crdoconnor 13y ago
>The problem with YAML is it's not safe by default Why would that be an issue when using it as a configuration format?
- coldtea 13y ago
  Because the parsers for that configuration format are unsafe too? Duh!
rat87 13y ago
I thought the problem wasn't with yaml but with allowing deserialize arbitrary objects which is unsafe by default for a format used both for 'trusted' and 'untrusted' input, If you have a json library which tries to allow deserializing arbitrary objects by default (with a load rather then unsafe_load method). Python's pickle serialization is unsafe but it warns you that its unsafe and is not widely used leading to it not being used as a serialization format for for unsafe input.

daGrevis 13y ago

We tried to use YAML at first, but problems with data types (can't correctly remember what, but there was no way to force something to be something) made us to rewrite our test fixtures to JSON. The only problem with JSON for us is that it doesn't support any comments, but JSON5 seems to fix it. There's a interesting format for configuration called TOML[1], you should check it out! [1] https://github.com/mojombo/toml https://github.com/mojombo/toml

coldtea 13y ago

>Are we seriously going to keep insisting on json as a configuration format? Yes. It has good universal support, often without needing any libraries, it's simple, succint, and has good tooling. >As Stormbrew already pointed out, we already have a format that is ideal for configurations (and sure, data exchange, why not), and it is called yaml. Let's just not go there. YAML is a pain in the ass to parse, has different incompatible versions, the libraries are of widely varying quality, is not natively (without third party stuff) supported in most languages, and it's generally a mess.

clarkevans 13y ago
There are lots of problems with YAML; it does too much. If I had time, I'd definitely want to do a 2.0 that gives it a small haircut removing the most bothersome of problems. I've been unable find time for work required: about a year of discussing, writing, coding, testing, packaging, and forging consensus. What I'd keep in YAML is the information model. When we started YAML ~12 years ago, it was obvious that configuration should be in XML, and that XML's information model was the correct way to organize data structures. Part of YAML's work was explaining a different way of doing things to those who'd otherwise use XML. This isn't a concern these days... That said, the productions look painful because the specification doesn't separate the scanner from the parser. Once you do that, the syntax is quite a bit more sane to grok (see PyYAML source). It's not nearly as bad as what you may think... IF you see it this way. Besides a few unfortunate syntax structures, YAML's complexity and sharp edges comes from it's venture into typed objects, type-spaces, and implicit typing. Much of this, for configuration files, is unnecessary. When we wrote YAML, we only had a few years experience with it; and well, it wasn't done as a full time endeavour. It was a guess as to how things should work. It wasn't easy to bootstrap YAML. It's now ten years later... and, well, lots of people have experience with it. It's probably time for the haircut.
- jrochkind1 13y ago
  oh, please do this. I love yaml -- except on the rare by very painful occasions where I get hugely bitten by incredibly weird problems arising from unexpected interplay of yaml features. Some of the originators of yaml are probably the only people who the social power to promulgate a revision with a haircut. That would be awesome.

SixSigma 13y ago

s-expressions

SimHacker 13y ago

YAML failed the intelligence test of getting its name right in the first place: "Yet Another Markup Language". YAML is NOT a markup language, in any way shape or form, yet the people who designed and named it earnestly thought they were designing a markup language, and that there was a need for yet another one. Only when somebody pointed out that obvious fact to them, did they come up with a recursive retronym to paper over their initial stupidity: "YAML Ain't Markup Language". How clever by half. I prefer to use formats that were designed by people who actually knew what they were doing and what it was called and how it was meant to be used.

kazagistar 13y ago

JSON Schema has a ton of implementations and tools hanging off of it. It is possible to load and validate a config, and then display a reasonably nice UI for editing it (in such a way that the resulting state is also valid), all by creating a single declarative JSON Schema. Nothing comparable exists for YAML as far as I can tell, and by virtue of its complexity, it is unlikely to exist for quite some time.