@gregchalmers raised the very valid point that allowing JSON null values everywhere in CF-JSON makes it difficult or maybe even impossible to define even a basic corresponding schema in OpenAPI 2 (i.e., for the two required and one optional member of the top-level object). In OpenAPI 3 we could use "nullable: true", but many of the packages / libraries we use at the moment don't support OpenAPI 3 yet.
We need null values (e.g., in variables with arrays of numbers where we don't want to enforce the missing_value attribute because it's more effort for the consumer), so don't want to generally forbid them in CF-JSON. But I don't see any disadvantages if we implicitly forbid them for the top-level object's members.
Proposed solution: specify that the top-level object's members must themselves be objects, which implies that they must not be null. Strictly speaking, this could invalidate some previously valid CF-JSON, but I can't imagine any practical impact at the moment.
For convenience, we should probably also provide an OpenAPI schema definition along with the spec.
@gregchalmers raised the very valid point that allowing JSON null values everywhere in CF-JSON makes it difficult or maybe even impossible to define even a basic corresponding schema in OpenAPI 2 (i.e., for the two required and one optional member of the top-level object). In OpenAPI 3 we could use "nullable: true", but many of the packages / libraries we use at the moment don't support OpenAPI 3 yet.
We need null values (e.g., in variables with arrays of numbers where we don't want to enforce the missing_value attribute because it's more effort for the consumer), so don't want to generally forbid them in CF-JSON. But I don't see any disadvantages if we implicitly forbid them for the top-level object's members.
Proposed solution: specify that the top-level object's members must themselves be objects, which implies that they must not be null. Strictly speaking, this could invalidate some previously valid CF-JSON, but I can't imagine any practical impact at the moment.
For convenience, we should probably also provide an OpenAPI schema definition along with the spec.