What's Wrong with StrictYAML

While I'm still delaying my position on TOML vs YAML holy war let's look at the StrictYAML.

StrictYAML is a type-safe YAML parser that parses and validates a restricted subset of the YAML specification.

Seems great but let's look at the removed features list, Implicit Typing to be precise:

Implicit Typing

x: yes
y: null

Example pyyaml/ruamel/poyo:

load(yaml) == {"x": True, "y": None}

Example StrictYAML without schema:

load(yaml) == {"x": "yes", "y": "null"}

What's wrong with this? Well, technically removal of these "features" is good and desired but it makes StrictYAML incompatible with YAML. So yes, StrictYAML spec is a subset of YAML spec but StrictYAML itself is not a subset of YAML, it essentially becomes a distinct language. StrictYAML file cannot be reliably parsed by a generic YAML parser.

This can be fixed by making string syntax always explicit but judging by author's position on syntax typing, it won't be.

It also gets worse:

Example StrictYAML with schema:

load(yaml, Map({"x": Bool(), "y": Str()})) == {"x": True, "y": "null"}

Schema induced type casts? Srsly?

In no definition of schema that I've found, practical or theoretical, schema is directly responsible for anything but validation. Schema definition must not influence the process of parsing, it's not why it exists. This not only makes StrictYAML even less compatible with YAML but also unleashes even greater evil than it tried to solve.

Interestingly, all other features are removed accurately and it really improves the language. Except maybe I don't agree about flow style. It makes YAML a superset of JSON which was announced as a feature and in my practice it was very useful from time to time. I see no real gain in removing it but at least it was done quite cleanly without breaking compatibility.

Comments

Comments powered by Disqus