I just discovered that the multiplicity of this attribute is not set at all in the AOM2 UML model. This is an error - it should be 0…1. The UML extractor defaults it to 1…1, which Archie is following and possibly other implementers are as well. I would like to fix this and make it optional, which just simplifies things a little bit more. Existing implementations could remain with 1…1 if they want, it would not be invalid.
@pieterbos - any thoughts on Archie? It seems to me looking at the code that you could just remove the default initialisation, but otherwise the code would be correct.
If SEC agreed to this, I would create a CR and also take care of the change in the UML and the spec.
The impact in Archie is removing the default initialisation, adding a @Nullable annotation, plus fixing a couple of tests. Then report in the release notes that this is a breaking change for any application using this field, that it can and will now be null and null-safety checks may have to be added to any code using this.
Or potentially just adding the @Nullable annotation, and not removing the default initialisation is also possible.
I don’t know if it’s simpler or not in practice. It will add more null-checks to code using this archetype, but it will be slightly easier to construct a valid archetype object.
I would prefer to at least fix the UML, but that will change the 1…1 to 0…1. It’s not a breaking change semantically, but it will slightly break software like Archie as described above. I’m still inclined to do it, but will wait for more feedback.