Using Layer 2 config for more than message validations

[vbabuEM]

The concept of Layer 2 Configuration was introduced with Beckn-ONIX a few months ago. The first implementation was aimed at reusing the existing request and response validations that happen at the Network Participants (currently on field only BAP and BPP Beckn Adaptors and not Registry/Gateway). Instead of using the core Beckn Transaction API yaml, network participants would now use the Layer 2 Config file which would be written to have all the core Beckn Transaction API validations as well as those defined by the network.

The Layer 2 Config defined this way has been found useful to write rules about request and response message formats. The rules might vary from marking a field as required, restricting values to enumerations to more advanced ones like conditional schema validations.

However while working with network facilitators, we have identified that this method of layer 2 config specification has a few deficiencies.

1. While the facility allows specifying rules within the current message, some of the business validations have been found to require rules that involve the state of the system (particularly validating something in the current message based on what was received before)
2. The json-schema has inherent restrictions on mathematical and value comparison rules. Some of these have been overcome through additional constructs defined by libraries, but not in the official json-schema and using them would impact compatibility across platforms.
3. Can Layer 2 rules be used to define rules outside of the messages. For example if the Network facilitator wants to define a set of attributes that every NP has to send to Observability Server, can these be written in Layer 2 Config.

Given these and similar scenarios, this discussion has been started to identify what options we have under the layer 2 config to define rules outside of structural message validation rules that are currently possible.

1. Should we define a new facility to specify such rules (Adding them to the OpenAPI yaml seems awkward)
2. If it is to be defined outside of OpenAPI, what would be a flexible format to both write it as well as validate it so as to build validations across technology platforms.

Please add to this discussion.

cc @ravi-prakash-v @sjthnrk @pramodkvarma @binrange @rajaneeshk90 @faizmagic @venkatramanm @tanya-ondc

[binrange]

Deficiency 1 and 2: These are still validation rules and hence do logically belong in the JSON schema. I wonder if these can be addressed in some fashion as an extension of JSON schema validations - maybe to be adopted in future versions of the JSON schema specifications?

Deficiency 3: (telemetry): This is clearly outside of the JSON schema intent. However, I am wondering if we can design something like the javadoc or pydoc or XML Documentation comments, that a parser can use to understand telemetry elements

[vbabuEM]

@binrange (Binu, ONDC), I am thinking of rewriting this issue to separate validation improvements from configuration requirements. Combining the two might be confusing. I will start two new discussions on the same. I hope that is ok.

[vbabuEM]

The configuration part is continued here:
#447