How fine-grained do we want to split up commands?

[enikao]

In #284, we decided to have fine-grained events, e.g. add/change/remove property as three commands instead of one.

We have other axes to decide upon granularity:

For references:

"entry" = [target, resolveInfo] tuple
We currently have 3 x 3 commands for (adding / changing / removing) x (entry / target / resolveInfo).
This could be reduced to 3 x 1.
Issue: If either target or resolveInfo is optional, but both of them can also be set to null, how to distinguish?

For annotations:

We currently mirrored all containment commands for annotations.
We could handle annotations with containment commands and assume "if feature == null we refer to annotations"

For annotations / containments

We currently have special commands for moving nodes between annotations and containments.
We could handle them without special commands if we assumed "feature == null refers to annotations"

[joswarmer]

This raises a question: do we allow instances of annotations to appear in a containment? I would expect not to allow this, but I cannot find this in the spec.

[enikao]

This raises a question: do we allow instances of annotations to appear in a containment?

We don't distinguish between them on serialization level -- they are all nodes, and only by their meta-pointer (and their containment) we can tell whether they are instances of annotations or concepts.

In M3, Link.type points to Classifier, so an annotation instance can appear in a containment.

[joswarmer]

On the serialisation level we allow many incorrect models according to their languages. My question is whether we find this valid with respect to the language definition. As you say, this is possible now.
But we need to improve this, as we need to either:

• add a constraint that annotates must be empty/null if the annotation instance is part of a containment, or
• don't allow instances of annotations to appear in a containment

[dslmeinte]

(These are equivalent statements: we can only disallow instances of annotations to appear in a containment by implementing a constraint.)

[joswarmer]

You are right! The choice still remains to be made.

[dslmeinte]

I'm very much in favor of adding the constraint :)