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
both locationFrom and LocationTo need to hove the same cardinality. Adding LocationToLocation -- "2" SupplierLocation doesn't work and wouldn't be clear
In general I believe that it would also be more clear if the cardinality on DataTypeProperties and ObjectProperties are indicated in the same way. Is there a specific reason why this is not the chosen approach in the present implementation?
The text was updated successfully, but these errors were encountered:
Yeah indeed that is not supported at the moment. The suggestion that you made is indeed a good solution for this.
In general I believe that it would also be more clear if the cardinality on DataTypeProperties and ObjectProperties are indicated in the same way. Is there a specific reason why this is not the chosen approach in the present implementation?
I did it this way because I didn't want to alter the default behaviour of Mermaid if need really needed.
How can one indicated the cardinality of a ObjectProperty if we have 2 ObjectProperties for the same class expecting the same class.
Example: suppose that I want to state that always 1 fromLocation is needed, and always 2 toLocations are needed
AS IS
class LocationToLocation {
string[] replenishmentMethods sc:replenishmentMethod 1..*
SupplierLocation locationFrom schema:fromLocation
SupplierLocation locationTo schema:toLocation
}
LocationToLocation -- "1" SupplierLocation
WANTED
class LocationToLocation {
string[] replenishmentMethods sc:replenishmentMethod 1..*
SupplierLocation locationFrom schema:fromLocation 1
SupplierLocation locationTo schema:toLocation 2
}
LocationToLocation -- SupplierLocation
In general I believe that it would also be more clear if the cardinality on DataTypeProperties and ObjectProperties are indicated in the same way. Is there a specific reason why this is not the chosen approach in the present implementation?
The text was updated successfully, but these errors were encountered: