2 ms·
If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would
by mcv 6y ago
If it ignores part of the spec, I don't think "strictyaml" is the correct name here. Instead, if it interprets everything as string, perhaps "stringyaml" would have been more accurate, though I'm sure that's not as good PR.
I'm reminded of the discussion we had a few days ago about environment variables; one problem there is that env variables are always strings, and sometimes you do want different types in your config. But clearly having the system automatically interpret whether it's a string or something else is a major source of bugs. Maybe having an explicit definition of which field should be which type would help, but then you end up with the heavy-handed XML with its XSD schema.
Or you just use JSON, which is light-weight, easy to read, but unambiguous about its types. I guess there's a good reason it's so popular.
Maybe other systems like yaml and environment variables should only ever be used for strings, and not for anything else, and I suppose replacing regular yaml with 'strictyaml' could play a role there. Or cause unending confusion, because it does violate the spec.
- povik 6y ago“saneyaml” would not make for bad PR
- marcinzm 6y ago>If it ignores part of the spec, I don't think "strictyaml" is the correct name here. The article didn't fully explain it but strictyaml requires a typed schema or defaults to string (or list or dict) if one is not provided. So it strictly follows the provided schema.
- mcv 6y agoThat makes a big difference indeed. It wasn't clear to me from the article, but string yaml + optional schema sounds like a useful combination.
- msiemens 6y ago> JSON, which is [...] unambiguous about its types With the one exception that with floatig point values the precision is not specified in the JSON spec and thus is implementation defined[1] which may lead to its own issues and corner cases. It for sure is better than YAML's 'NO' problem, but depending on your needs JSON may have issues as well [1]: https://stackoverflow.com/questions/35709595/why-would-you-use-a-string-in-json-to-represent-a-decimal-number https://stackoverflow.com/questions/35709595/why-would-you-u...
- wongarsu 6y agoAlso JSON's complete lack of many commonly used types, and no way to define any new ones.
- mcv 6y agoIsn't that a problem with most of these config languages, though? XML is the only one where I think this might be possible.
- wongarsu 6y agoAllowing you to define types is quite uncommon, but many config languages allow more types than JSON (so more than boolean, number, string, list, dict). Date datatypes are a big one and are provided by about every second JSON variant, in addition to TOML, ION and others.