We made the following decisions:

• We will use openapi as internal schema model for validation

• no incremental change to a schema definition via liquibase. We always provide the full schema.

• conversion from XSD => Openapi happens in liquibase layer, CM thinks only in Openapi

On 1. How CM will validate configuration from property file?
I see 2 ways:
1. Each schema type (e.g. xml and properties) defines their own way to deal with validation
2. We create a unified internal representation of schemas and validate against that. This could be
2.a XSDs (we would have to create internally a XSD from the Liquibase input)
2.b some other form of schema representation

Suggestion how the liquibase handling of properties could look like:

Assumptions

• The property key is unique within the schema

• Each property is mandatory (otherwise we can't show it in the GUI), therefore

• Each property has a default value

• When a property is removed from the schema we remove it from all configuration instances

Food for thoughts:

In the POC we envisioned defining a properties schema as following:

https://github.com/opennms-forge/notconfd/blob/main/liquib/src/main/resources/changelog.xml

https://github.com/OpenNMS/opennms/blob/1975dbbb5ac2d1e34780414f73830cd2a46744f1/core/cm/changelog-29.0.0.xml#L22