json-schema-org / vocab-idl

Help and clarify how JSON Schema can be interpreted from validation rules to data definition. This extends to how those data definitions can be represented in any programming language

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Constants

gregsdennis opened this issue · comments

I initially questioned the need to communicate constants.

If a constant is defined in a programming language, it's intended not to change, and it's likely hardcoded. This means that there's usually no real reason to serialize that value unless some other system needs to know what that value is, in which case it's not a constant in the other system; it's just another variable. It's just data.

However from a codegen point of view, if you're designing the interface that's intended to generate code for multiple systems, maybe you want to define some constants in an common/agnostic format so that the values will be set properly in each target system.

So while constants as a language construct don't generally apply to data transmission (run-time), they can be useful at dev-time to align multiple systems.

To generate a constant, an implementation will need

  • a name for the constant
  • a type for the data
  • an initialization value

The name and value can be accomplished with the current keyword set in JSON Schema, but I think the type needs a new keyword.

{
  "title": "myConst",
  "dataType": {"$ref": "#/$defs/myDataType"},
  "default": "some value",
}

The type defined by dataType will need to be generated at some point.

In a validation context, dataType will simply be a single-schema applicator, much like additionalProperties or then.