Merging strategy for the schema registry.

[TeresiaOlsson]

@JeanLucPons and @gupichon I made this discussion to easier discuss the steps and merging strategy for the schema registry since there are now many different parts we have discussed related to this and I need some guidance in which order to implement things.

This is my suggestion for the steps:

1. Add SchemaRegistry, SchemaValidator and SchemaGenerator while restricting changes to other modules as much as possible. This means adding a way to register the existing ConfigModels without changing them or the domain classes.

2. Add functionality to dynamically generate the schema from the constructor of the domain class and remove the ConfigModels.

3. Add the functionality to automatically validate when creating an object.

It is also a question if the merge should be done directly into main? Or should there be a separate branch that all the steps should be merged into before the final version including all steps are merged into main?

[TeresiaOlsson]

@JeanLucPons What do you mean by "categories by categories rather than features" here: python-accelerator-middle-layer/pyaml#264 (comment)

[JeanLucPons]

I mean you start with BPM only.
This will force you to handle both legacy stuff and new stuff in each PR.
And you will learn from each PR.
It is a good exercise.
Then when it will be ended, we will remove legacy stuff.

[TeresiaOlsson]

Yes, that's a good idea. I think I will try with one that doesn't inherit from Element because that one affects many other classes.

[JeanLucPons]

OK bon courage 😉

[TeresiaOlsson]

I have decided to go for the RF package first. It includes a nested model but seems easier than the BPM as a first start.