3 ms·

I have a love-hate relationship with YAML. Hate: - human-wise ambiguity of its syntax (If I understand correctly, you "can" indent array items, but you don't

by k_sze 5y ago

I have a love-hate relationship with YAML. Hate: - human-wise ambiguity of its syntax (If I understand correctly, you "can" indent array items, but you don't have to. And than one guys says "OK, I'm gonna indent", and another guy says "Nah. I'm not gonna indent") - still no support for datetime as a first class citizen - strings usually don't need quotes, until they do (I prefer to always quote) Note that two of the above points are about allowing inconsistent styles, which is a thing I hate. Love: - it supports comments whereas JSON does not. If the IETF ever officially updated JSON to support C-style inline (and maybe block) comments, I would absolutely ditch YAML.

thayne 5y ago
So use any of a dozen or so other configuration formats that have comments but don't have all the problems YAML does. TOML is probably the most popular of those right now.
- deleted 5y ago
  [deleted]
- k_sze 5y ago
  TOML is good for config, but not for data exchange though. (Why would I need comments in a data exchange format? Comments are useful when you want to annotate some sample data for other developers who will consume or generate that data.) Also, OpenAPI specs (also known colloquially as Swagger) can only be written in JSON or YAML.
  - makeitdouble 5y ago
    Your requirements seem to be getting pretty close to XML territory. To note, JSON specifically doesn’t have comments to close the door to annotations and other kind of meta use.
  - thayne 5y ago
    Agreed, so use JSON for data exchange and TOML for configuration. YAML isn't all that great for data exchange either. In the cases where you have a tool that require json or yaml, you could use something like cue, dhall, or jsonnet, and convert it into json (or yaml). Unfortunately, that's a little tricky when your build cinfiguration itself has to be in yaml, as is the case for github actions, travis-ci, etc.
kstenerud 5y ago
You might get a kick out of Concise Encoding then (shameless plug). It focuses on security and consistency of behavior. And it supports comments and has first class date types ;-) https://concise-encoding.org/ https://concise-encoding.org/ In particular: * How to deal with unrepresentable values: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#unrepresentable-values https://github.com/kstenerud/concise-encoding/blob/master/ce... * Mandatory limits and security considerations: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#security-and-limits https://github.com/kstenerud/concise-encoding/blob/master/ce... * Consistent error classification and processing: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#error-processing https://github.com/kstenerud/concise-encoding/blob/master/ce...
Fannon 5y ago
The simplest solution here would be to use JSON5 (https://json5.org/ https://json5.org/) if you're after comments. It still doesn't support / standardize dates, though. But realistically, it's also all about the ecosystem. VSCode for example doesn't come with JSON5 support out of the box. GitHub and many other tools / renderers and supports it at least in syntax highlighting.
- Koffiepoeder 5y ago
  Maybe they should try to file an RFC update/new spec? I would be all for it, since it is backwards compatible and covers some essential new needs of a modern configuration syntax. It seems they already have some notable people included in the project, making it more plausible to succeed as a succession to RFC8259.

by k_sze 5y ago

thayne 5y ago

So use any of a dozen or so other configuration formats that have comments but don't have all the problems YAML does. TOML is probably the most popular of those right now.

deleted 5y ago
[deleted]
k_sze 5y ago
TOML is good for config, but not for data exchange though. (Why would I need comments in a data exchange format? Comments are useful when you want to annotate some sample data for other developers who will consume or generate that data.) Also, OpenAPI specs (also known colloquially as Swagger) can only be written in JSON or YAML.
- makeitdouble 5y ago
  Your requirements seem to be getting pretty close to XML territory. To note, JSON specifically doesn’t have comments to close the door to annotations and other kind of meta use.
- thayne 5y ago
  Agreed, so use JSON for data exchange and TOML for configuration. YAML isn't all that great for data exchange either. In the cases where you have a tool that require json or yaml, you could use something like cue, dhall, or jsonnet, and convert it into json (or yaml). Unfortunately, that's a little tricky when your build cinfiguration itself has to be in yaml, as is the case for github actions, travis-ci, etc.

kstenerud 5y ago

You might get a kick out of Concise Encoding then (shameless plug). It focuses on security and consistency of behavior. And it supports comments and has first class date types ;-) https://concise-encoding.org/ https://concise-encoding.org/ In particular: * How to deal with unrepresentable values: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#unrepresentable-values https://github.com/kstenerud/concise-encoding/blob/master/ce... * Mandatory limits and security considerations: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#security-and-limits https://github.com/kstenerud/concise-encoding/blob/master/ce... * Consistent error classification and processing: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#error-processing https://github.com/kstenerud/concise-encoding/blob/master/ce...

Fannon 5y ago

The simplest solution here would be to use JSON5 (https://json5.org/ https://json5.org/) if you're after comments. It still doesn't support / standardize dates, though. But realistically, it's also all about the ecosystem. VSCode for example doesn't come with JSON5 support out of the box. GitHub and many other tools / renderers and supports it at least in syntax highlighting.

Koffiepoeder 5y ago
Maybe they should try to file an RFC update/new spec? I would be all for it, since it is backwards compatible and covers some essential new needs of a modern configuration syntax. It seems they already have some notable people included in the project, making it more plausible to succeed as a succession to RFC8259.