Message reshaping rules

Message reshaping

This document is a proposal for the rules to reshape a message. It has been split into the two processes involved in reshaping, flattening and the removal of fixed values.

Conventions

When a class is removed from the serialization it is virtualized, this term will be used to describe this process from now on in this document.

This document will discuss the prepending of class names to attributes. When a message is sent it will actually be the association name that gets prepended.

The rules will not be applied when the class or association has been marked as not to be flattened.

Where a business name has been specified this will be used instead of prepending association names.

When a count of attributes is mentioned this will always be after attributes with fixed values have been removed according to the rules below. This doesn’t include attributes inherited from child associations.

Removal of fixed values

Structural attributes

If the value is listed as being fixed (=) then the attribute is not to be included in the flattened model.

Class attributes

For coded attributes, if a fixed value has been specified the attribute is not to be included in the flattened model.

Flattening

Act - ActRelationship - Act

When the Act is a leaf class and has two attributes or less (having removed fixed attributes) then the following shall happen:

• The Act shall be virtualized
• The child attributes shall have the Act name prepended to their name followed by a period eg. Observation.value.
• The child attributes shall then be inherited by the parent ActRelationship

When the ActRelationship has two or less attributes:

• The ActRelationship shall be virtualized
• The ActRelationship class name shall be prepended to the child attributes and the attributes of the entity followed by a period.
• All attributes shall be promoted to the parent Act

The parent Act will be flattened as the descendant of a parent Act – ActRelationship – Act relationship.

Entity - Role - Participation - Act

Where the entity is a leaf class and there two attributes or less then the following shall happen:

• The entity shall be virtualized
• The Entity shall have the Role name prepended to its name followed by a period eg. performer.assignedEntity.
• The child attributes shall then be inherited by the parent act

If the role has less than two attributes then the following shall happen:

• The role shall be virtualized
• The role class name shall be prepended to the child attributes and the attributes of the entity followed by a period.
• All attributes shall be promoted to the parent participation

If the participation has got less than two attributes (after fixed values are removed) then the following shall happen:

• The participation shall be virtualized.
• The participation name shall be prepended to the child attributes

Entity - Role - Entity

Starting from the leaf entity the following rules shall be applied:

If the Entity class has two attributes or less then the following shall happen:

• The Entity shall have the Role name prepended to its name followed by a period eg. performer.assignedEntity.
• The child attributes shall then be inherited by the parent act

Where the Role class has two attributes or less:

• The Role class will be virtualized
• The attributes will be promoted to the parent Entity

Issues:

The repetition of names needs to be dealt with, e.g patient.patientPerson. Recommendation: A business name should be specified where repetition of names occurs.

Should flattening occur across model boundaries? Recommendation: flattening should occur across model boundaries unless specified in the referencing model that it shouldn’t occur for this model boundary.

Should a limit be set for the number of attributes that a class can contain in the algorithm?