special casing fallback behavior when attribute is set to null will make it more difficult to tool against

[tylerjw]

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.

[tylerjw]

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/""/[]/{}.

[tylerjw]

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.

[autoantwort]

Imho we should simply remove that. This also makes it harder to write a schema for it.

[mwoehlke]

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.

[mwoehlke]

On further consideration, I think we have two different cases here:

• Attributes with known names: Omitting the attribute, setting it to null, or setting it to an empty value (e.g. "", []) are equivalent. Tools will "see" these attributes by querying for them directly, and may explicitly request the value as e.g. a string. In this case, it is convenient for unspecified and null to be equivalent to empty, as many JSON libraries will provide a null when a non-existing attribute is requested without checking for its existence, and will implicitly provide an "empty" value when asked to convert a null. Thus, it is helpful for all three (unspecified, explicit null, logical empty) to be equivalent.
• Attributes with dictionary values: In this case (e.g. requires, compile_definitions), the keys are not known in advance and must be enumerated. This means that a key not in the object is inherently different from a key explicitly specified as having a null value. The latter may (or may not, as in compile_definitions) be equivalent to an empty value.

So, I think there are two questions that need to be answered here:

• Are there examples of named attributes for which omission differs from explicitly specifying a logical empty? If so, can we eliminate those?
• Do "structural" parsers which fill a value of dictionary type treat explicit null as unspecified or as an empty value? (Note that these will have trouble with compile_definitions.)