Always provide both containment and parent id in serialization

[enikao]

In a tree, the relation between parent and child is bi-directional.
In our serialization format, we have such a relation for each Containment.

Option A: Store child id in parent

Example:

{
  "type": "Car",
  "id": "1111",
  "children": {
    "wheels": [
      "2222",
      "2223"
    ]
  }
},
{
  "type": "MetalWheel",
  "id": "2222"
},
{
  "type": "AluminiumWheel",
  "id": "2223"
},

Pro:

• Efficient top-down navigation

Con:

• Need to build up child-to-parent relation during parsing

Option B: Store parent id in child

Example:

{
  "type": "Car",
  "id": "1111"
},
{
  "type": "MetalWheel",
  "id": "2222",
  "parent": "1111"
},
{
  "type": "AluminiumWheel",
  "id": "2223",
  "parent": "1111"
},

Pro:

• We know the parent even if it's not part of the currently serialized model chunk
• We don't need another Repo API call "get me the parent of this node"

Con:

• Need to build up parent-to-child relation during parsing

Option C: Store both

Example:

{
  "type": "Car",
  "id": "1111",
  "children": {
    "wheels": [
      "2222",
      "2223"
    ]
  }
},
{
  "type": "MetalWheel",
  "id": "2222",
  "parent": "1111"
},
{
  "type": "AluminiumWheel",
  "id": "2223",
  "parent": "1111"
},

Pro:

• Combines all pros of option A and B
• Both directions are explicitly stored

Con:

• Duplicate information might waste space
• Have to handle inconsistent information

-> Decision: Option C
Space issues can be addressed by compression in lower protocol level (#73).

[enikao]

I think we should explicitly define what happens if parent and child id don't match, or some node declares itself as parent.

Example:

{
  "type": "Car",
  "id": "1111",
  "children": {
    "wheels": [
      "2222",
      "2223" // `parent` mismatch
    ]
  }
},
{
  "type": "MetalWheel",
  "id": "2222",
  "parent": "2222" // "I'm my own parent"
},
{
  "type": "AluminiumWheel",
  "id": "2223",
  "parent": "2222" // `children` mismatch
},

[enikao]

Do we want to call the containment list children or containments? The latter would be more in line with M3 terminology, but a bit further away from commonly used terms.
Also, the current children nicely mirrors the parent field (as proposed by this issue). For containments, it would be container, but that's very confusing. (Until today, I have to think about containment vs. container each time again when using EMF.)

[dslmeinte]

I'd prefer children and parent: it's nicely symmetric, without being confusing. "containments" I tend to interpret as "the features of a concept which are of type Containment", but that's probably just me.

[enikao]

Decision on name of children field via Slack vote: Keep children name

Rationale: Commonly used term. Also plays well with descendants. How would you name that if the children are called containments? transitiveContainments? subtree?

[enikao]

Proposal by @ftomassetti instead of references: referred (to stay more symmetrical with children)

[joswarmer]

I think decision C (which is flagged as the one taken) is probably the worst. It means we ship redundant information, and make things much more likely to become inconsistent.
I prefer A, as it is simple, and as the parent is conceptually the one "in charge", i.e. if the parent is deleted, the child does not exist / is not reachable anymore. So this feels as the most natural one to me.

Ad C: also has con Need to build up child-to-parent relation during parsing is of course also there. It's a consequence of using a flat list., not of having either parent and/or child info in the format.

[joswarmer]

I think referred lacks the notion of being many, while references does, therefore I prefer references .

[joswarmer]

After some more thought, I retract my opinion that C is worst.

[joswarmer]

This discussion trigger a new question, wrote it down in #75

[enikao]

Decision on name of references field via Slack vote: We keep names references / reference as in:

{
  "children": {},
  "references": {
    "roleName": [
      {
        "resolveInfo": "Foo",
        "reference": "20avxv10-123"
      }
    ]
  },
  "parent": "lxkdfjhw34p"
}