You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The compatiblewith feature is currently just a label in the metamodel and not a top-level property of the metamodel.
The information that a model is compatible to a shared model understanding is really important to get interoperability beyond the own xRegistry scope and make a shared ecosystem around the model standard possible.
I wonder if this is obvious enough, as understanding that one model in xRegistry A is compatible with another Model in xRegistry B (usually via the same shared model contract, e.g. the CNCF Domain Specific Specifications) is crucial.
It would be helpful if a model export / import can carry this information and that the implications of it are clear to the xRegistry admins. Not sure if the current solution via labels is good enough for this or not, @duglin could judge better.
What I worry about: Let's say a company hosts their own xRegistry server and imports the message definitions model and customize it. How would an external xRegistry or consumer know that the model is compatible with their own understanding? It is possible to customize models in a way that they are not interoperable anymore. In that case, it would not be possible to use a shared ecosystem around that model (like we can do for OpenAPI / AsyncAPI).
The text was updated successfully, but these errors were encountered:
The
compatiblewith
feature is currently just a label in the metamodel and not a top-level property of the metamodel.The information that a model is compatible to a shared model understanding is really important to get interoperability beyond the own xRegistry scope and make a shared ecosystem around the model standard possible.
I wonder if this is obvious enough, as understanding that one model in xRegistry A is compatible with another Model in xRegistry B (usually via the same shared model contract, e.g. the CNCF Domain Specific Specifications) is crucial.
It would be helpful if a model export / import can carry this information and that the implications of it are clear to the xRegistry admins. Not sure if the current solution via labels is good enough for this or not, @duglin could judge better.
What I worry about: Let's say a company hosts their own xRegistry server and imports the message definitions model and customize it. How would an external xRegistry or consumer know that the model is compatible with their own understanding? It is possible to customize models in a way that they are not interoperable anymore. In that case, it would not be possible to use a shared ecosystem around that model (like we can do for OpenAPI / AsyncAPI).
The text was updated successfully, but these errors were encountered: