| > When I’m reading the `maxItems` property from it, I know it’s an integer. Why do I need the document author to also tell me it’s an integer? Because this allows well-designed client libraries to detect conflicts between the document-author intent and programmer intent, enabling mismatches to fail as errors rather than being read other-than-as-intended. > For statically typed languages, you have to tell it what type you’re expecting, so it can interpret the value at that point. Yes and a client in such a language should fail (or have a mode in which it fails) if the value is not actually, as read in YAML semantics, a type compatible with what you are asking for. > Even for dynamic language, most of the time you still want to validate the types up front to avoid an incorrect type blowing up in a random place in your code. So write a schema, use the schema to drive how the values are interpreted. Schemas are for validation, not interpretation. If you use them for interpretation, then you get JavaScript-esque weak typing, and the errors that come with it (basically, magnifying the kind of YAML 1.1 problems that YAML 1.2 tamped down.) > By replacing all the non-structural types with string, you can have the clean quote less format they’re after but without any of the “Norwegian problem” issues. What you propose is an explosion of Norway-problem-style potential for values to be interpret other than as intended by the document author, not a mitigation. |