I've long thought there's a fundamental conflict between style portability (which is a non-negotiable requirement) and the freedom to use custom data.
But maybe I'm wrong, and there's some reasonable way?
Regardless, we need a mechanism to allow flexibility in the data model, whether it's through a formal extension mechanism, or a process that makes it easy to add new fields.
I will say the current code base already likely covers the latter; adding a new field would typically just be adding a value to some enum with a documentation string.
EDIT: the data model is now strongly-typed, so an invalid JSON or YAML import (e.g. with an unknown field) will panic.
OTOH, if some of the others ideas here (see #89) pan out, maybe we don't care about style portability as much?
I've long thought there's a fundamental conflict between style portability (which is a non-negotiable requirement) and the freedom to use custom data.
But maybe I'm wrong, and there's some reasonable way?
Regardless, we need a mechanism to allow flexibility in the data model, whether it's through a formal extension mechanism, or a process that makes it easy to add new fields.
I will say the current code base already likely covers the latter; adding a new field would typically just be adding a value to some
enumwith a documentation string.EDIT: the data model is now strongly-typed, so an invalid JSON or YAML import (e.g. with an unknown field) will panic.
OTOH, if some of the others ideas here (see #89) pan out, maybe we don't care about style portability as much?