5 ms·

Having fought with YAML just recently I suggest the media type application/garbage. The format is filled with strange footguns.

andoma 3y ago
no
- 01HNNWZ0MV43FF 3y ago
  --- true
milliams 3y ago
Are you referring to things like the boolean "NO" string (i.e. the "Norway Problem") or another issue?
- grumbel 3y ago
  The handling of multi-line strings is needlessly complex and can easily end up in white-space getting eaten unintentionally.
  - deathanatos 3y ago
    … really? I feel like for multi-line strings, I almost always use |, and only |. It takes the indented block as-is, which I feel like is going to be what you'd want … always? I think maybe once, ever, I used > to fold some whitespace…? I know the chomping & indent indicators exist, but I feel like I've only ever seen those in programmatically generated YAML. I have trouble envisioning a real-world use-case that is going to make me pull them out. They're a facet of the language that feels as if it exists solely for a processor that might need to emit any possible string, which | would not permit, and the inline strings might be uglier. That said … there is a post like yours in every YAML thread. But I think those of us that understand YAML … I'm having a hard time grokking what you're doing that causes consternation.
    - TomSwirly 3y ago
      > It takes the indented block as-is, which I feel like is going to be what you'd want … always? What if you are writing primarily paragraphs? What if you want extra blank lines at the end of a block? Or no carriage return at all? In my reading, unscientifically I feel I see the `>` text formatter most often, then almost as often `|`, then `>-` occasionally, then `>+` just one time.
      - deathanatos 3y ago
        That's a big what-if, I guess. If you're okay with line wrapping … do line-wrapping & |, if you're not … don't do line wrapping & |? I'm not usually putting prose into YAML, outside of comments. I think most of my blocks are scripts, small data files, long queries, the like. That's sort of why I was looking for a (perhaps non-hypothetical) use case.
    - neuromanser 3y ago
      > for multi-line strings, I almost always use |, and only |. It takes the indented block as-is Except it doesn't. Try using steps: - run: | > f echo not redirected in Github Actions.
meowface 3y ago
StrictYAML provides a subset of YAML without the annoying footguns: https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/
- Quekid5 3y ago
  Oh, how I wish we could get an RFC for that instead.
  - clcaev 3y ago
    indeed, would be a good idea
- aidenn0 3y ago
  YAML 1.2 addresses several of those: - Duplicate keys are not allowed - The fallback schema gives you no Implicit Typing and Direct representations of objects for free (the former explicity, the latter by restricting which tags are allowed). Schemata in general allow for doing the "right thing" for your domain more easily.
rcarmo 3y ago
Even considering I adopted YAML as an easy format to manage append-only tabular data (all the tables in my site are written in YAML), I have to agree with this and would second the vote for that media type.
TomSwirly 3y ago
I finally ran into the "on" bug just last month with github workflows: the default .yml file github writes has an unquoted `on` as a key to a dictionary, and pyyaml "correctly" interprets that as `True`. I can imagine this would have been baffling if I hadn't read about it before. There wasn't actually an elegant solution, but replacing `\n on:` with `\n "on":` was an acceptable hack that took two minutes.
- Karellen 3y ago
  FTA: > Section 10.3.2 of [YAML] specifies that only the scalars matching the regular expression `true|True|TRUE|false|False|FALSE` are interpreted as booleans. Older YAML versions were more tolerant (e.g., interpreting `NO` and `N` as `False` and interpreting `YES` and `Y` as `True`). When the older syntax is used, a YAML implementation could then interpret `{insecure: n}` as `{insecure: "n"}` instead of `{insecure: false}`. Using the syntax defined in Section 10.3.2 of [YAML] prevents these issues. > [YAML] Ben-Kiki, O., Evans, C., dot Net, I., Müller, T., Antoniou, P., Aro, E., and T. Smith, "YAML Ain't Markup Language Version 1.2", 1 October 2021, <https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/>.
swozey 3y ago
I went through this recently trying to heavily use yaml anchoring to determine various k/v's from a .yml config file, and yeah, it was awful. But I think the biggest problem for me was every single yaml library I tried in various languages (go, rust, python, ruby) was just not good. IIRC only one of them (rubys syck I think) even supported anchors, which is a yaml standard, and NONE of them could read anchors to know where in the yaml file the scan was happening. So I wound up having to literally crawl tab/indents, specify what symbol anchors where /& and store that and rebuild everything. I THOUGHT I could just say "goto &anchor, copy &data to anchor, anchor, anchor, *anchor.." but nothing knew what &anchor was! What's the point of having a spec with &anchor if your library does literally nothing with it? I'm sure someones dealt with this probably in a more elegant way than me.
anticensor 3y ago
no no, miscellanous/garbage-input

andoma 3y ago

01HNNWZ0MV43FF 3y ago
--- true

milliams 3y ago

Are you referring to things like the boolean "NO" string (i.e. the "Norway Problem") or another issue?

grumbel 3y ago
The handling of multi-line strings is needlessly complex and can easily end up in white-space getting eaten unintentionally.
- deathanatos 3y ago
  … really? I feel like for multi-line strings, I almost always use |, and only |. It takes the indented block as-is, which I feel like is going to be what you'd want … always? I think maybe once, ever, I used > to fold some whitespace…? I know the chomping & indent indicators exist, but I feel like I've only ever seen those in programmatically generated YAML. I have trouble envisioning a real-world use-case that is going to make me pull them out. They're a facet of the language that feels as if it exists solely for a processor that might need to emit any possible string, which | would not permit, and the inline strings might be uglier. That said … there is a post like yours in every YAML thread. But I think those of us that understand YAML … I'm having a hard time grokking what you're doing that causes consternation.
  - TomSwirly 3y ago
    > It takes the indented block as-is, which I feel like is going to be what you'd want … always? What if you are writing primarily paragraphs? What if you want extra blank lines at the end of a block? Or no carriage return at all? In my reading, unscientifically I feel I see the `>` text formatter most often, then almost as often `|`, then `>-` occasionally, then `>+` just one time.
    - deathanatos 3y ago
      That's a big what-if, I guess. If you're okay with line wrapping … do line-wrapping & |, if you're not … don't do line wrapping & |? I'm not usually putting prose into YAML, outside of comments. I think most of my blocks are scripts, small data files, long queries, the like. That's sort of why I was looking for a (perhaps non-hypothetical) use case.
  - neuromanser 3y ago
    > for multi-line strings, I almost always use |, and only |. It takes the indented block as-is Except it doesn't. Try using steps: - run: | > f echo not redirected in Github Actions.

meowface 3y ago

StrictYAML provides a subset of YAML without the annoying footguns: https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/

Quekid5 3y ago
Oh, how I wish we could get an RFC for that instead.
- clcaev 3y ago
  indeed, would be a good idea
aidenn0 3y ago
YAML 1.2 addresses several of those: - Duplicate keys are not allowed - The fallback schema gives you no Implicit Typing and Direct representations of objects for free (the former explicity, the latter by restricting which tags are allowed). Schemata in general allow for doing the "right thing" for your domain more easily.

rcarmo 3y ago

Even considering I adopted YAML as an easy format to manage append-only tabular data (all the tables in my site are written in YAML), I have to agree with this and would second the vote for that media type.

TomSwirly 3y ago

I finally ran into the "on" bug just last month with github workflows: the default .yml file github writes has an unquoted `on` as a key to a dictionary, and pyyaml "correctly" interprets that as `True`. I can imagine this would have been baffling if I hadn't read about it before. There wasn't actually an elegant solution, but replacing `\n on:` with `\n "on":` was an acceptable hack that took two minutes.

Karellen 3y ago
FTA: > Section 10.3.2 of [YAML] specifies that only the scalars matching the regular expression `true|True|TRUE|false|False|FALSE` are interpreted as booleans. Older YAML versions were more tolerant (e.g., interpreting `NO` and `N` as `False` and interpreting `YES` and `Y` as `True`). When the older syntax is used, a YAML implementation could then interpret `{insecure: n}` as `{insecure: "n"}` instead of `{insecure: false}`. Using the syntax defined in Section 10.3.2 of [YAML] prevents these issues. > [YAML] Ben-Kiki, O., Evans, C., dot Net, I., Müller, T., Antoniou, P., Aro, E., and T. Smith, "YAML Ain't Markup Language Version 1.2", 1 October 2021, <https://yaml.org/spec/1.2.2/ https://yaml.org/spec/1.2.2/>.

swozey 3y ago

I went through this recently trying to heavily use yaml anchoring to determine various k/v's from a .yml config file, and yeah, it was awful. But I think the biggest problem for me was every single yaml library I tried in various languages (go, rust, python, ruby) was just not good. IIRC only one of them (rubys syck I think) even supported anchors, which is a yaml standard, and NONE of them could read anchors to know where in the yaml file the scan was happening. So I wound up having to literally crawl tab/indents, specify what symbol anchors where /& and store that and rebuild everything. I THOUGHT I could just say "goto &anchor, copy &data to anchor, anchor, anchor, *anchor.." but nothing knew what &anchor was! What's the point of having a spec with &anchor if your library does literally nothing with it? I'm sure someones dealt with this probably in a more elegant way than me.

anticensor 3y ago

no no, miscellanous/garbage-input