Community
Participate
Working Groups
Almost certainly a WONTFIX, but I think the discussion is worth having Bugzilla'd. The default lowerBound for UML is 1, so a default feature in UML is not nullable, i.e. cannot be null and also be well-formed. Ecore tooling consistently provides a zero default, so that in the Sample Ecore Editor a 1 bound must be entered explicitly and a corresponding 1 annotation appears in the icon. UML2 tooling provides a one default, and suppresses the multiplicity annotation in the UML2 model editor when it would be [1]. The MDT/OCL Examples OCLinEcore editor currently follows Ecore, so entry of name : String round-trips to show name : String[?] explicitly. Resolving this surprise and aligning with UML suggests that OCLinUML should default to a 1 lowerBound, requiring the [?] to be entered explicitly to get a 0 lower bound. Should the Ecore behaviour be regarded as an unfortunate tradition that new tooling should rectify, or an important behaviour that new tooling should preserve?
It's clearly not something we'd change. In the Ecore tree view we show multiplicities a certain way (with 0..1 being implicit as it's the default). I don't consider it an unfortunate mistake. What does EMOF say about it?
There's nothing to fix in Ecore.
MOF 2.0 is the UML way, so this is a MOF/Ecore semantic difference.
There are actually 3 different defaults. The Ecore.ecore default clearly must not change to avoid breaking already serialized meta-models. The Sample Ecore Editor icon default could acquire a 0..1 decoration to avoid any confusion for users unaware of the distinct MOF/Ecore behaviour. Tools such as the Sample Ecore Editor could apply a 1 rather than 0 lower bound default on new user input, so that a newly created EAttribute is 1..1 rather than 0..1. This would make new entry MOF-compatible without affecting serialization. It was interest in any strong opinion for/against the analoguous change in the OCLinEcore editor that prompted this discussion.
I doubt any users have any EMOF expectations because there don't appear to be any other tools that support it. I'm not interested in changing long established behavior either. Probably an OCL editor ought to decorate in a way consistent with the Ecore editors...
