Who updates resolveInfo in references on name changes?

[enikao]

For references, we optionally store resolveInfo as a text representation of the target. If the target implements INamed, we often use its name property as resolveInfo.

Assume the name of node A changes, who is responsible for updating the resolveInfo in all references pointing to A?

[dslmeinte]

At the moment, computing the resolveInfo string is entirely the responsibility of the serializer, and doesn't have a “free-standing” status—it's also not configurable in the current reference implementations. So, conceptually, the resolveInfo might not even (be allowed to) play a part in a delta!

However, that's not practical, so maybe we want to shore up its status a bit? We probably should have a separate delta (event) type to broadcast a change to the resolveInfo of a particular reference. But unless we formalize the computation of a resolveInfo (which could be quite context-specific), I don't think we can do much right away.

[enikao]

At the moment, computing the resolveInfo string is entirely the responsibility of the serializer

I understand this differently: resolveInfo is just as much part of the model as target, thus has to be set by some client explicitly. The serializer has no business in changing that information on its own.

[joswarmer]

In the spec:

If a Reference.type targets a Classifier that implements INamed, implementations SHOULD use the target’s name property as default resolveInfo value.

Would shoring up mean something like replacing SHOULD with MUST?

[enikao]

I'd prefer to keep it open -- a DSL might chose to have a better value, e.g. a FQN instead of the target's simple name.

[dslmeinte]

Exactly: using a name doesn't mean it's just that name. At the same time, I'd like to avoid some kind of marking mechanism on the M2-level (so reified as concepts in M3) for specifying how a FQN is built up.