5 ms·
RFC 9512: YAML Media Type
- djha-skin 3y agoThe authors come from the Italian government, axway, and Mozilla. I wonder if this is being standardized like this because of a government requirement for standardization before use in official work, as is often the case. Axway's flagship seems to be an api marketplace platform. Does anybody else have insight into what interest these parties might have in a Yaml RFC?
- ucarion 3y agoRoberto Polli and Erik Wilde are frequent IETF contributors. I'm not following their work much these days, but I don't think they have a specific interest here. They're active in httpapi, the working group that produced this RFC. Having worked a bit with both, they're great and thoughtful folks. Eemeli Aro maintains the 'yaml' npm package. Seems like a good person to have aboard make sure things stay practical.
- giantrobot 3y agoHaving fought with YAML just recently I suggest the media type application/garbage. The format is filled with strange footguns.
- andoma 3y agono
- 01HNNWZ0MV43FF 3y ago--- true
- milliams 3y agoAre you referring to things like the boolean "NO" string (i.e. the "Norway Problem") or another issue?
- grumbel 3y agoThe 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 agoThat'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
- meowface 3y agoStrictYAML provides a subset of YAML without the annoying footguns: https://hitchdev.com/strictyaml/features-removed/ https://hitchdev.com/strictyaml/features-removed/
- Quekid5 3y agoOh, how I wish we could get an RFC for that instead.
- clcaev 3y agoindeed, would be a good idea
- aidenn0 3y agoYAML 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 agoEven 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 agoI 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 agoFTA: > 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 agoI 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 agono no, miscellanous/garbage-input
- noirscape 3y ago> .yaml is the preferred extension, .yml is dated Is this really true? Basically every project I've ever cloned or set up that relied on YAML still uses .yml as the extension.
- milliams 3y agoI assume that it's because people are still struggling to move away from 8.3 filenames (https://en.wikipedia.org/wiki/8.3_filename https://en.wikipedia.org/wiki/8.3_filename).
- deathanatos 3y agoI mean … probably depends on local preferences. Every project I've ever worked on used .yaml. .yml feels like .htm to me. DOS is long since gone. But, Github seems to think they're about the same, with a lead for .yml: 23.9M hits for .yml, 17.8M for .yaml.
- BandButcher 3y agoI cringe at .htm
- gweinberg 3y agoWouldn't the analog of .htm be .yam?
- WorldMaker 3y agoI've always used .yaml and have never understood why someone would choose .yml. Three letter extensions haven't been a requirement since like DOS 5 and I can't imagine that many developers are both using YAML and still using FAT16 but can't afford VFAT long filename entries.
- deleted 3y ago[deleted]
- cesarb 3y ago> I've always used .yaml and have never understood why someone would choose .yml. Because it's what the documentation says. For instance, the "Getting Started" example at https://docs.flatpak.org/en/latest/first-build.html https://docs.flatpak.org/en/latest/first-build.html says "call it org.flatpak.Hello.yml" - and that's Flatpak, which has always been a Unix-specific thing.
- riffic 3y agogreat, now do markdown! edit: markdown has been done too :) https://datatracker.ietf.org/doc/html/rfc7763 https://datatracker.ietf.org/doc/html/rfc7763 https://datatracker.ietf.org/doc/html/rfc7764 https://datatracker.ietf.org/doc/html/rfc7764
- benatkin 3y agoIt's good that it identifies it as a family of languages, and doesn't make it refer to original markdown, which doesn't have code fences.
- mhitza 3y agoDoes anyone know what's the rationale for settling on application/yaml instead of text/yaml? Couldn't find on within the text.
- vbernat 3y agoSame as for application/json I suppose: this is a structured format to be processed by an application, not by humans directly.
- wiktor-k 3y agoThere's one issue with text, it defaults to ASCII: > For example, for any MIME type whose main type is text, you can add the optional charset parameter to specify the character set used for the characters in the data. If no charset is specified, the default is ASCII (US-ASCII) unless overridden by the user agent's settings. To specify a UTF-8 text file, the MIME type text/plain;charset=UTF-8 is used. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_...
- paulddraper 3y agoMany text types default to other encodings. E.g. text/vcard https://www.iana.org/assignments/media-types/text/vcard https://www.iana.org/assignments/media-types/text/vcard
- arp242 3y agoThat's fine, no? Not like application/anything can default to the correct character set. This is why everyone typically uses application/json; charset=UTF-8.
- creatonez 3y agoIf you don't have a content type, you're screwed no matter what you do. Web browsers use a goofy detection system that sometimes works and sometimes fails, because it only reads the beginning of the file.
- michael1999 3y ago
- nmz 3y agoHow can there be an RFC for something that is not implementable by anything other than the main yaml library?
- aidenn0 3y agoI wrote a YAML parser several years ago. It wasn't that hard. YAML block literals can be confusing to write, but are not at all hard to parse.