Open LBlaive opened 4 months ago
I'm not against compositions appearing on multiple diagrams if they provide useful context. In this case it might be argued that the addition of NamedArea emphasises that it is the depicted LocationReferencing::NamedArea that is needed for use by another class in LocationReferencing, while abstract NamedArea is used for other purposes, but then it would be consistent to also show the Common usage of the abstract NamedArea. Maybe the note is enough. Overall, I can agree to hide the composition between AreaLocation and NamedArea.
I would note that when we look at such situations, it is not a good idea to spend much resources while the model is still in v3. The new models must use v4 features and in particular the composition graph will significantly change, with compositions being reduced to relationships between D2Entities and to graphically highlight a few major components. Most v3 compositions will become attribute types. At the moment it seems a bit that all model editors jump on addressing the issues, while leaving the transformation into v4 models for the end. I find this approach not helpful. The v4 mechanisms will change the way we draw diagrams.
This issue needs to be considered anyway. The editor suggests hiding the “AreaLocation” class in the class diagram.
Note: A lot of issues present on GitHub are about Version 3. They need to be tacked in a way or another. If applying the new methodology changes the data model drastically, it is not sure that many mentioned issues will disappear ipso facto.
During the 2024-10-15 meeting the issue was considered positively. Therefore, the "AreaLocation" class and the corresponding composition with "NamedArea" are removed from the class diagram.
What happened?
Comment reported during the Formal Vote ballot in 2018 by FR (no FR099). in this class diagram of this package the composition between "NamedArea" and "AreaLocation" appears. The same composition already appeared in the "AreaLocation" class diagram. It is the only case in the DATEX II data model of such duplication. Is there any reason justifying this specific treatment? If no, hide the class. If yes, add the corresponding explanation,
Version
3
Code of Conduct