Selection of a JSON Schema Validation Strategy

[PaulFarault]

I am considering several strategies for validating variable files against JSON schemas and would like to open up a discussion to help select the most effective approach.

Below are the current strategies I've identified, along with some pros and cons for each. I'm eager to hear your thoughts, feedback, or any additional options I might not have considered!

JSON Schema Validation Strategies

A single service can have either none, one or multiple schema defined among collections.

1. Individual Schema Validation (current approach)

   • Each schema is validated one by one.
   • Limitations: This approach doesn’t allow us to override definitions across schemas, limiting flexibility in certain use cases.

2. Concatenate Schemas into a Single Schema

   2.1. Using allOf (initial approach)

   • Combines multiple schemas with allOf for a unified validation.
   • Limitations: While structured, this approach doesn’t allow for definition overrides and requires pre-processing of subschemas to ensure proper injection.

   2.2. Manual Concatenation

   • Manually merging schemas to create a single, consolidated schema.
   • Advantages: Allows for definition overrides.
   • Challenges: This approach is more complex to implement and maintain.

3. Last Schema in Collection Validation

   • Only the last schema loaded for a service among all collection is used for validation.
   • Example: Given collections c1 > c2:
     • If a schema for "service" exists in c1 but not in c2, the schema from c1 validates c2 variables.
     • If schemas for "service" exist in both c1 and c2, then the c2 schema extends c1.
     • Overrides are validated by the schema in the last-loaded collection.
   • Considerations: This approach moves the responsibility of schema extension to each collection, making it more adaptable but potentially adding complexity to schema definition in each collection.

I'm interested in hearing your feedback on:

• Which strategy you think might work best.
• Any technical or practical challenges you foresee with each approach.
• Any alternative strategies you’ve used or recommend.

Thanks in advance for your input. Looking forward to a productive discussion!

[wdavidw]

In Nikita, all actions define an associated schema. It maximizes the usage of $ref to enforce composability. Take the example of nikita.incus.cluster which behaves just like vagrant up. Each property refers to the JSON schema of a sub-action.

For example, the disk object of a container object refers to the nikita.incus.config.device action:

{
  "disk": {
    "type": "object",
    "default": {},
    "patternProperties": {
      ".*": {
        "$ref": "module://@nikitajs/incus/config/device#/definitions/disk/properties/properties"
      }
    }
  }
}

You'll notice that the configuration of a Nikita action is not the JSON schema but registered as the config property. Internally, all the schemas are registered inside a metadata.definitions action's property. This allows Nikita to optionally provide schema validation for the configuration input object, to expose subschemas to other actions (just like /definitions/disk/properties/properties above), and to validate other action's information such as the action's output.

It is also perfectly fine to use allOf, oneOf, and other JSON schema constructs. Taking the nikita.incus.config.device action schema as an example, a device is oneOf disk, nic, ... and how a nic is oneOf physical, bridge, ...