Open Fak3 opened 4 years ago
Actually I wonder whether we should just drop the use of relationship class and instead just enumerate each value as a separate relationship in the uml too. Actually the source model from UN is like that already - abd we convert to relationship class when generating the model
@onthebreeze & @Fak3 Is there any instruction to follow and update for me ?
@onthebreeze & @Fak3 Is there any instruction to follow and update for me ?
We have not come to the decision yet, put it on hold for now
We discussed json serialization rules with @onthebreeze, decided to go forward with solution proposed at https://github.com/edi3/edi3-uml-profile/issues/8. So below are the new rules for handling qualified relationships (relationship class):
Simple relation case When in the model the relationship class only contains single property (qualifier) which has limited set of allowed values (i.e. typed as enumeration), then for all possible values of that property (qualifier) in the model (values from the enumeration), the JSON schema of the source class should have the corresponding property (json key) with the name equal to that value. Each such property should have a schema generated in the same way as if it represented an unqualified relationship from source to the target entity, i.e. have type: array and that array items should have type:object and that object should include all identifying properties of the target class. So in the example above, if MovementPartyRole_Code could have values of operator or owner, the schema for TransportMovement should include two array properties, correspondingly named operator and owner. Items of that array should be objects, and have a $ref to the schema, called TransportMovementParty. TransportMovementParty schema should declare two properties - Identification and Name (from Party class).
Complex relation case {TODO} - I will create another ticket