cps-org
special casing fallback behavior when attribute is set to null will make it more difficult to tool against
Note that a value of null satisfies the condition of having the attribute. A value of null
has the usual meaning where null is an acceptable value for the attribute; otherwise, a value
of null shall be treated as the attribute being unset (and shall suppress falling back to the
non-configuration-specific value).
In JSON parsers, where you specify a structure of types and the parser tries to fill out those types, typically an unset attribute and an attribute set to null both results in a None value in an optional. In cases where you must tell the difference between an unset value and a null value, you'll end up with a nested option type. This makes it much more challenging to tool around this spec.
It would be much easier if tag: null meant the same as the tag not being specified. If you want to unset the values and not allow a fallback, set the value to an empty string or array. For example tag: [] or tag: "" would cause an overriding to an empty value.
It would be easier to tool against this if it read:
Note that a null value is the same thing as not specifying the attribute. To suppress
falling back to the non-configuration-specific value, specify a valid value such as
0/""/[]/{}.
I found another use of this sort of special-casing null here: https://cps-org.github.io/cps/schema.html#requires-package
Values are a valid requirement object or null (equivalent to an empty requirement object)
describing the package required.
I prefer this wording for the sake of tooling:
Values are a valid requirement object or an empty object.
Imho we should simply remove that. This also makes it harder to write a schema for it.
I prefer this wording [...]
Yes, I guess we should change that also, but an empty object is a valid Requirement; "or an empty object" is redundant.
Values are a valid requirement object
describing the package required.
