6 ms·

If the JSON and YAML folks can’t get along, I swear I’ll turn this car around and make you all use XML.

by QuinnyPig 7y ago

CameronNemo 7y ago
inb4 YAML adds "Yeah, nah." and "Nah, yeah." as boolean values. Interpretation is locale dependent.
- crdoconnor 7y ago
  That's why StrictYAML always interprets as string unless there's a schema. Cuts out the surprise type conversions.
- Master_Odin 7y ago
  YAML 1.2 fixed this making booleans just true/false and it's a real shame that a lot of things still use 1.1
  - wrs 7y ago
    I’m sure Christopher True and Robert False really appreciate that “fix”.
    - reneberlin 7y ago
      So true. Your comment made my day.
  - erik_seaberg 7y ago
    I don't like NO as a boolean literal (mostly because it's also an ISO country code), but there's only one right way to parse it in a YAML 1.1 document. It was a mistake to apply the 1.2 rules to 1.1 documents and issue a "warning" about incorrect output, rather than require rejecting the document if the 1.1 rules aren't implemented.
- EdwardDiego 7y ago
  I'd also like "Sweet" to be true and "Stink" to be false.
sipos 7y ago
To be fair, the article begins by linking to a previous article by the same author about the problems with JSON. He is an equal opportunities opponent :)
jackfraser 7y ago
Aren't we just reinventing the wheel, though? Got your structured data format, now you need parsers (tons available for XML, incl SAX, DOM parsers, SimpleXML, Nokogiri...) a schema and validation tools (XSD), a templating mechanism (XSLT), a query language (XPath), ... JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Better parser interfaces that help you treat the dataformat more like it's part of the language would also help (i.e. SAX and DOMDocument suck to work with, but SimpleXML is almost idiomatic).
- saghm 7y ago
  > JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read
  - EGreg 7y ago
    Look. I am just a web guy. But why is XML so freaking great? We can’t even tell if whitespace is significant or not. If a schema says it’s insignificant then that’s that! https://www.oracle.com/technetwork/articles/wang-whitespace-092897.html https://www.oracle.com/technetwork/articles/wang-whitespace-... That alone is TERRIBLE! (Same problem with YML.) Why should I bother with that? JSON can encode strings, hashes, arrays etc. in a way that’s instantly interoperable with JS and is far far more unambiguous. What exactly is so great about XML that you can’t do with JSON in a better way? Schemas can be stored in JSON. XPATH can specified for JSON. Seriously I never got the appeal of XML except that it was first.
    - tannhaeuser 7y ago
      XML wasn't meant as replacement for JSON, but for HTML without vocabulary-specific parsing rules (eg. SGML DTDs).
    - 7y ago
quotemstr 7y ago
You say that like it'd be a bad thing. I like XML.
- _eht 7y ago
  You say that like you’ve never really used XML... (Mostly /s. Come at me:))
  - quotemstr 7y ago
    I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't. My one request would be to bring back to SGML-like closing tag abbreviation: That is, instead of <foo><bar>qux</bar></foo> we should be able to write <foo><bar>qux</></> I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.
    - _eht 7y ago
      Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.
      - quotemstr 7y ago
        Why? It's no worse than S-expressions.
        WillPostForFood 7y ago
        The verbosity makes it harder to parse. It is subjective, but I find ")))" is a lot easier to instantly parse as 3 than "</></></>"
        _eht 7y ago
        It’s significantly worse than single char s expression for my eye, anyway.
    - deleted 7y ago
yakubin 7y ago
I'd prefer XML because of the stability of the tools available for it. Recently I was writing a custom static site generator for my website. I started with python and yaml using the pyyaml lib. After two months (don't laugh, I wasn't writing this generator all this time; i had a break) I tested if everything I wrote previously was warking. Pyyaml came at me screaming that they deprecated something and I shouldn't use it, otherwise the feds will get me. Let's go several months earlier still. I was learning Python, using Debian Stretch which has Python 3.5 installed. The book I was learning from used Python 3.7. When I got to a point it became clear that 3.5 lacks a few things which are needed to continue learning Python according to the book. So I compiled Python 3.7, set up virtualenv with it and... The code I had previously written stopped working. With a version bump from 3.5 -> 3.7? That's a minor version change. And now 3.5 was expecting at one point to have a string path passed as an argument, and 3.7 was expecting a pathlib path. That was trivial to fix in case of a small example, but I would dread using such a thing for anything big and then having to debug what exactly broke between different (minor!) versions of Python or its libraries. These new hip tools seem to have a backwards-compatibility issue. I eventually settled on using XSLT and a couple really short shell scripts (which all fit on my screen at the same time) and I don't expect them to break in the next two decades. However, XML is still a pain and I would prefer just using S-expressions and Lisp[1]. It's just that for now my only experience with them is writing things for Emacs and I would like to learn Scheme/CommonLisp to do anything outside of Emacs with Lisp. [1] https://sites.google.com/site/steveyegge2/the-emacs-problem https://sites.google.com/site/steveyegge2/the-emacs-problem
- pietroglyph 7y ago
  This sounds more like a Python and pyyaml problem than a YAML or JSON problem. Someone could come along and totally refactor XSLT even if XML stayed the same, and then you would be in the same boat.
  - ColanR 7y ago
    Parent addressed your comment in his first sentence. > I'd prefer XML because of the stability of the tools available for it.
rhizome 7y ago
I have to wonder if these stories are written by people who simply hate to type, or aren't good at it. Beyond that I can only chalk it up to academic curiosity.

If the JSON and YAML folks can’t get along, I swear I’ll turn this car around and make you all use XML.

CameronNemo 7y ago

inb4 YAML adds "Yeah, nah." and "Nah, yeah." as boolean values. Interpretation is locale dependent.

crdoconnor 7y ago
That's why StrictYAML always interprets as string unless there's a schema. Cuts out the surprise type conversions.
Master_Odin 7y ago
YAML 1.2 fixed this making booleans just true/false and it's a real shame that a lot of things still use 1.1
- wrs 7y ago
  I’m sure Christopher True and Robert False really appreciate that “fix”.
  - reneberlin 7y ago
    So true. Your comment made my day.
- erik_seaberg 7y ago
  I don't like NO as a boolean literal (mostly because it's also an ISO country code), but there's only one right way to parse it in a YAML 1.1 document. It was a mistake to apply the 1.2 rules to 1.1 documents and issue a "warning" about incorrect output, rather than require rejecting the document if the 1.1 rules aren't implemented.
EdwardDiego 7y ago
I'd also like "Sweet" to be true and "Stink" to be false.

sipos 7y ago

To be fair, the article begins by linking to a previous article by the same author about the problems with JSON. He is an equal opportunities opponent :)

jackfraser 7y ago

Aren't we just reinventing the wheel, though? Got your structured data format, now you need parsers (tons available for XML, incl SAX, DOM parsers, SimpleXML, Nokogiri...) a schema and validation tools (XSD), a templating mechanism (XSLT), a query language (XPath), ... JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Better parser interfaces that help you treat the dataformat more like it's part of the language would also help (i.e. SAX and DOMDocument suck to work with, but SimpleXML is almost idiomatic).

saghm 7y ago
> JSON was a reaction to the verbosity of XML, but a better reaction would have been to work harder on our text editors so that working with XML would be just as easy as working with JSON in terms of the numbers of keystrokes needed. Isn't that only solving half the problem? XML is also pretty difficult to read
- EGreg 7y ago
  Look. I am just a web guy. But why is XML so freaking great? We can’t even tell if whitespace is significant or not. If a schema says it’s insignificant then that’s that! https://www.oracle.com/technetwork/articles/wang-whitespace-092897.html https://www.oracle.com/technetwork/articles/wang-whitespace-... That alone is TERRIBLE! (Same problem with YML.) Why should I bother with that? JSON can encode strings, hashes, arrays etc. in a way that’s instantly interoperable with JS and is far far more unambiguous. What exactly is so great about XML that you can’t do with JSON in a better way? Schemas can be stored in JSON. XPATH can specified for JSON. Seriously I never got the appeal of XML except that it was first.
  - tannhaeuser 7y ago
    XML wasn't meant as replacement for JSON, but for HTML without vocabulary-specific parsing rules (eg. SGML DTDs).
  - 7y ago

quotemstr 7y ago

You say that like it'd be a bad thing. I like XML.

_eht 7y ago
You say that like you’ve never really used XML... (Mostly /s. Come at me:))
- quotemstr 7y ago
  I've used it quite a bit. I even like the namespacing bits. I find that XML composes elegantly in a way that the JSON and friends don't. My one request would be to bring back to SGML-like closing tag abbreviation: That is, instead of <foo><bar>qux</bar></foo> we should be able to write <foo><bar>qux</></> I think this one change would make XML more "palatable" for the JSON/YAML/TOML crowd.
  - _eht 7y ago
    Interestingly I find SGML-esque to be quite unpalatable. I get the feeling doing code reviews would be nightmarish.
    - quotemstr 7y ago
      Why? It's no worse than S-expressions.
      - WillPostForFood 7y ago
        The verbosity makes it harder to parse. It is subjective, but I find ")))" is a lot easier to instantly parse as 3 than "</></></>"
      - _eht 7y ago
        It’s significantly worse than single char s expression for my eye, anyway.
  - deleted 7y ago

yakubin 7y ago

I'd prefer XML because of the stability of the tools available for it. Recently I was writing a custom static site generator for my website. I started with python and yaml using the pyyaml lib. After two months (don't laugh, I wasn't writing this generator all this time; i had a break) I tested if everything I wrote previously was warking. Pyyaml came at me screaming that they deprecated something and I shouldn't use it, otherwise the feds will get me. Let's go several months earlier still. I was learning Python, using Debian Stretch which has Python 3.5 installed. The book I was learning from used Python 3.7. When I got to a point it became clear that 3.5 lacks a few things which are needed to continue learning Python according to the book. So I compiled Python 3.7, set up virtualenv with it and... The code I had previously written stopped working. With a version bump from 3.5 -> 3.7? That's a minor version change. And now 3.5 was expecting at one point to have a string path passed as an argument, and 3.7 was expecting a pathlib path. That was trivial to fix in case of a small example, but I would dread using such a thing for anything big and then having to debug what exactly broke between different (minor!) versions of Python or its libraries. These new hip tools seem to have a backwards-compatibility issue. I eventually settled on using XSLT and a couple really short shell scripts (which all fit on my screen at the same time) and I don't expect them to break in the next two decades. However, XML is still a pain and I would prefer just using S-expressions and Lisp[1]. It's just that for now my only experience with them is writing things for Emacs and I would like to learn Scheme/CommonLisp to do anything outside of Emacs with Lisp. [1] https://sites.google.com/site/steveyegge2/the-emacs-problem https://sites.google.com/site/steveyegge2/the-emacs-problem

pietroglyph 7y ago
This sounds more like a Python and pyyaml problem than a YAML or JSON problem. Someone could come along and totally refactor XSLT even if XML stayed the same, and then you would be in the same boat.
- ColanR 7y ago
  Parent addressed your comment in his first sentence. > I'd prefer XML because of the stability of the tools available for it.

rhizome 7y ago

I have to wonder if these stories are written by people who simply hate to type, or aren't good at it. Beyond that I can only chalk it up to academic curiosity.