Keep serialization order between different features?

[enikao]

For each node, we serialize these lists:

• properties
• children
• references
• annotations

Do we define an ordering between different features or feature kinds?
(Ordering within the same feature is discussed in #157.)

"Ordering between features" means we could intermix children of different roles, or references of different roles.

"Ordering between feature kinds" means we could intermix arbitrarily e.g. children, properties, and annotations.

Assume this language:

concept Person {
  property publicName: String
  property firstName: String
  property lastName: String
  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
}

Option A: Don't allow intermixing

The order of features and feature kinds is undefined. Any LIonWeb client is free to serialize them in any order, and may or may not keep the order when serializing back the (unchanged) model.

Pro:

• Can by supported by most existing systems
• Matches MPS' "external" approach (i.e. how the APIs work)

Con:

• Doesn't support all use cases (see other options)

Option B: Allow intermixing within the same kind

The order of feature kinds is undefined, but within the same feature kind the feature order must be maintained.

Example:

Person P {
  [address] Address { mainStreet }
  [car] Auto { Lotus }                      // car at mainStreet
  [address] Address { mountainWay }
  [car] Motorcycle { Honda }         // car at mountainWay

  [friends] --> D
  [siblings] --> D
  [siblings] --> E
  [friends] --> F

  lastName = Doe
  publicName = J. Doe
  firstName = John

Pro:

• Allows correlation of different features of the same kind
• Matches MPS' "internal" approach for children (i.e. how the storage works)
• Allows ordering properties

Con:

• Serious change to serialization format

Option C: Allow any intermixing

The order of any feature, independent of their kind, must be maintained.

Example:

Person P {
  publicName = J. Doe

  [address] Address { mainStreet }
  [car] Auto { Lotus }                      // car at mainStreet
  [friends] --> D                            // lives also at MainStreet
  firstName = John                       // D calls P by this name
  [siblings] --> D
  <annotation> Tag { Blonde }
  [siblings] --> E

  [address] Address { mountainWay }
  lastName = Doe
  [car] Motorcycle { Honda }         // car at mountainWay
  [friends] --> F
  <annotation> Comment { Known to know stuff }

  <annotation> Tag { Adult }
}

Pro:

• Allows correlation of different features of the same kind
• Allows ordering properties

Con:

• Serious change to serialization format
• Lots of additional complexity without clear benefit: What would be the use case of ordered features of arbitrary kind?
• If really needed, can be simulated by containment of a generic concept with appropriate specializations