4 ms·

> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is al

by bhaak 8y ago

> JSON didn't exist (YAML is a parallel, contemporary effort). Interesting. How did it happen then that, quoting the YAML 1.2 spec, that "every JSON file is also a valid YAML file"? Although the previous spec documents don't mention JSON. Was that an intentional design decision for 1.2 or was it some kind of convergent design due to Javascript?

ngrilly 8y ago
The answer is in version 1.2 of the spec: > The primary objective of this revision is to bring YAML into compliance with JSON as an official subset.
clarkevans 8y ago
I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of us in 1999 (from SML-DEV list). In January of 2001 we picked the name and had early releases. It took a few years of iteration before we had a specification the collaborators (Perl, Python, and Ruby) could all bless. Anyway, with regard to Crawford's excellent work, JSON. It is a coincidence that YAML's in-line format happened to align. Although, it's probably because of a "C" ancestor, not JavaScript. The main influence on the YAML syntax was RFC0822 (e-mail), only that from my perspective, it needed to be a typed graph. In fact, we documented where we stole ideas from, to the best we could recall at that time: http://yaml.org/spec/1.0/#id2488920 http://yaml.org/spec/1.0/#id2488920.
- crdoconnor 8y ago
  >YAML is complex and could use a hair cut. Out of curiosity, did you see the parser linked to at the end of the article? ( https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml ) That was my attempt at giving YAML a haircut. I'd be curious to know what you thought. Thank you for creating YAML, by the way. Even though part of that rant was quoted from me, I'm not negative on it like the author - I think the core was brilliantly designed. If you put two hierarchical documents side by side - one in TOML and another in YAML the YAML one is much, much clearer and cleaner.
  - freedomben 8y ago
    Is there an implementation of strict yaml that you know of for Ruby?
    - bmurphy1976 8y ago
      If you are writing a new YAML implementation, then yeah, you want a simpler spec to follow. If on the other hand you are using a YAML library... I've had pretty good success using YAML compatibly across Python, Ruby, C# and Go projects. Do you have a particular issue in mind that the existing Ruby implementation doesn't address?
      - dillnumber0 8y ago
        It's an implementation of YAML, not StrictYAML which has different semantics.
      - freedomben 8y ago
        Yes, strict YAML is different than YAML. If you take a look at the github page linked in the GP, it explains the differences.
  - clarkevans 8y ago
    Thank you for StrictYAML I might just use it. It does look like a nice hair cut. You might wish to give Ingy a ring. He has been itching to move forward on a reduced/secure YAML subset. That said, StrictYAML seems to be a tad bit more of a hair cut than I'd imagine. I'd keep nodes/anchors, since I think a graph storage model is underrated; I think that data processing techniques just haven't caught up with graph structures. Further, I'm not sure everything can be easily typed based upon a schema. Hence, I'm not sure about completely dropping implicit types, perhaps you may want to provide a way for applications to resolve them if they wish. For example, an application may want to attempt to treat anything starting with "[" or "{" as JSON sub-tree. Perhaps keeping "!tag" but handing it off to the application to resolve might also be a good idea in this regard. Even so, typing should be done at the application level and default to something very boring.
- ramses0 8y ago
  "JSON didn't exist because Us and We"? YAML is an invented serialization format, JSON is a discovered one. As CrOCKford points out, JSON existed as long as JS existed, he just called it out and put a name on it. Anyway, XML is a strong anti-pattern (too much security, even if you get it right on your end, the other party likely screwed something up). YAML seems to be going down that path too. TOML seems to be "the JSON of *.ini" (ie: discovering old conventions, rather than inventing new ones), and I'm glad to have been exposed to it.
  - clarkevans 8y ago
    > "JSON didn't exist because Us and We"? If you define JSON as the underlying practice that Crawford later named and documented, then sure, what I wrote reads completely wrong headed. However, when we were working on YAML, JSON was not yet called out and given a name. I believe the most important convention that YAML and JSON shared was a recognition of the typed map/list/scalar model used by modern languages. Further, as far as conventions go, I think there's quite a bit to be said about languages that use light-weight structural markers such as: indentation, colon and dash.

by bhaak 8y ago

ngrilly 8y ago

The answer is in version 1.2 of the spec: > The primary objective of this revision is to bring YAML into compliance with JSON as an official subset.

clarkevans 8y ago

I have admired Douglas Crawford's excellent JSON from the moment I saw it, it is a model of simplicity. I also like TOML and wish it all the best. By contrast, YAML is complex and could use a hair cut. When I say "JSON didn't exist", what I mean is that it wasn't popular or known to us when we were working on YAML. So, please excuse my sloppy wording. For me, the work on what would become YAML started with a few of us in 1999 (from SML-DEV list). In January of 2001 we picked the name and had early releases. It took a few years of iteration before we had a specification the collaborators (Perl, Python, and Ruby) could all bless. Anyway, with regard to Crawford's excellent work, JSON. It is a coincidence that YAML's in-line format happened to align. Although, it's probably because of a "C" ancestor, not JavaScript. The main influence on the YAML syntax was RFC0822 (e-mail), only that from my perspective, it needed to be a typed graph. In fact, we documented where we stole ideas from, to the best we could recall at that time: http://yaml.org/spec/1.0/#id2488920 http://yaml.org/spec/1.0/#id2488920.

crdoconnor 8y ago
>YAML is complex and could use a hair cut. Out of curiosity, did you see the parser linked to at the end of the article? ( https://github.com/crdoconnor/strictyaml https://github.com/crdoconnor/strictyaml ) That was my attempt at giving YAML a haircut. I'd be curious to know what you thought. Thank you for creating YAML, by the way. Even though part of that rant was quoted from me, I'm not negative on it like the author - I think the core was brilliantly designed. If you put two hierarchical documents side by side - one in TOML and another in YAML the YAML one is much, much clearer and cleaner.
- freedomben 8y ago
  Is there an implementation of strict yaml that you know of for Ruby?
  - bmurphy1976 8y ago
    If you are writing a new YAML implementation, then yeah, you want a simpler spec to follow. If on the other hand you are using a YAML library... I've had pretty good success using YAML compatibly across Python, Ruby, C# and Go projects. Do you have a particular issue in mind that the existing Ruby implementation doesn't address?
    - dillnumber0 8y ago
      It's an implementation of YAML, not StrictYAML which has different semantics.
    - freedomben 8y ago
      Yes, strict YAML is different than YAML. If you take a look at the github page linked in the GP, it explains the differences.
- clarkevans 8y ago
  Thank you for StrictYAML I might just use it. It does look like a nice hair cut. You might wish to give Ingy a ring. He has been itching to move forward on a reduced/secure YAML subset. That said, StrictYAML seems to be a tad bit more of a hair cut than I'd imagine. I'd keep nodes/anchors, since I think a graph storage model is underrated; I think that data processing techniques just haven't caught up with graph structures. Further, I'm not sure everything can be easily typed based upon a schema. Hence, I'm not sure about completely dropping implicit types, perhaps you may want to provide a way for applications to resolve them if they wish. For example, an application may want to attempt to treat anything starting with "[" or "{" as JSON sub-tree. Perhaps keeping "!tag" but handing it off to the application to resolve might also be a good idea in this regard. Even so, typing should be done at the application level and default to something very boring.
ramses0 8y ago
"JSON didn't exist because Us and We"? YAML is an invented serialization format, JSON is a discovered one. As CrOCKford points out, JSON existed as long as JS existed, he just called it out and put a name on it. Anyway, XML is a strong anti-pattern (too much security, even if you get it right on your end, the other party likely screwed something up). YAML seems to be going down that path too. TOML seems to be "the JSON of *.ini" (ie: discovering old conventions, rather than inventing new ones), and I'm glad to have been exposed to it.
- clarkevans 8y ago
  > "JSON didn't exist because Us and We"? If you define JSON as the underlying practice that Crawford later named and documented, then sure, what I wrote reads completely wrong headed. However, when we were working on YAML, JSON was not yet called out and given a name. I believe the most important convention that YAML and JSON shared was a recognition of the typed map/list/scalar model used by modern languages. Further, as far as conventions go, I think there's quite a bit to be said about languages that use light-weight structural markers such as: indentation, colon and dash.