Maintain order in serialization of each containment / reference / annotation

[enikao]

For each node, we serialize these lists:

• properties
• children
• references
• annotations

We exclude properties from this issue, as we don't allow multiple values per property.
Thus, they fall into scope of #156.

What requirements do we have on the order of children / references / annotations?

Assume this language:

concept Person {
  containment addresses: Address[0..*]
  containment cars: Vehicle[0..*]
  reference siblings: Person[0..*]
  reference friends: Person[0..*]
}

annotation Tag {
  multiple = true
  annotates = Person

  property name: String
}

annotation Comment {
  multiple = false
  annotates = Node

  property text: String
}

and this instance:

Person P {
  addresses: [
    Address { mainStreet }
    Address { mountainWay }
  ]

  cars: [
    Auto { Lotus }
    Motorcycle { Honda }
  ]

  siblings: [
    --> C
    --> D
  ]

  friends: [
    --> D
    --> E
  ]

  annotations: [
    Tag { Adult }
    Comment { Known to know stuff }
    Tag { Blonde }
  ]
}

For each of

• mainStreet / mountainWay
• Lotus / Honda
• --> C / --> D
• --> D / --> E
• Adult / Known to know stuff / Blonde
  We have the following options:

Option A: Order is undefined

The order of serialization is undefined. Any LIonWeb client is free to chose their order, and may or may not keep the order when serializing back the (unchanged) model.

Pro:

• Very simple to implement
• Can be supported by most existing systems

Con:

• Very surprising to the user: They create the model with order mainStreet / mountainWay, and after reloading it might show mountainWay / mainStreet

Option B: Order must be maintained

The order of serialization is relevant. Any LIonWeb client needs to keep the order as-is, unless the order is explicitly changed (e.g. the user reorders the entries).

Pro:

• In line with user expectations

Con (copied from #4):

• For automatic merging / diffing, explicitly knowing the order doesn't matter is very useful
• Collaborative modeling / distributed data structures can handle unordered collections a lot easier

Option C: Order by defined criteria

For example, entries are ordered by their ID, or some other criteria.

Pro:

• Order inherent to the data, so serialization order is irrelevant

Con:

• Finding sensible criteria is hard
• Very un-intuitive for users: The add a new entry somewhere, and it might jump somewhere else based on the ordering criteria

Decision: Option B - Order must be maintained

[joswarmer]

As we have decidec on option B, I think we can close this issue.

[joswarmer]

Should close this