[not final] [AIXM-400] Forward-backward data mapping strategy

Some change proposals might be fully 1:1 mappable between versions. For example, the change of a code used in a list of values without a change of the meaning. The mapping rules are provided directly in the change proposal concerned.

In this case, a new value (“NEW_VAL”) is added in the new version to an existing AIXM CodeList or an existing value is deleted, as highlighted in the UML class diagram to the right.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

The forward mapping approach proposed in this case is as follows:

• Replace “OTHER:NEW_VAL” with “NEW_VAL”
• Replace “OLD_VALUE” with “OTHER:OLD_VALUE”

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

The backward mapping approach proposed in this case is as follows:

• Replace “NEW_VAL” with “OTHER:NEW_VAL”

In this case, a new attribute (“newAtribute”) or a new association to another feature (“newAssociation”) is added to an existing class, as highlighted in the UML class diagrams to the right.

The new property models information that could not be coded in the existing version. Therefore, no data from the existing version can be mapped into the new attribute.

For the backwards mapping, several options are possible: 

• in case the data recipient is not interested in the new information, the element may simply be removed. This option being straightforward, it is not further detailed.
• in case the data recipient needs the new information in structure format, an extension of the previous AIXM version needs to be defined and used. Obviously, this requires a system upgrade. This option being straightforward, it is not further detailed.
• as an intermediate solution, the new property may be converted into an annotation. This will not be suitable for automatic processing, but it might be still useful in case the data recipient is interested to know that the new information exists. In addition, if the new property is logically related to an existing property, the backwards created Note can be specified as being associated with that existing property.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

Not applicable.

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

From the three backward mapping options discussed above, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:

• Remove the new element
• Add an annotation.Note associated with the owner class having

• purpose=“OTHER:BACKWARD_MAPPING”;
• translatedNote.LinguisticNote.note=”newValue: <newValue> <uom>, where
• <newValue> is the actual value of the newAttribute or of the newRole.xlink:href;
• <uom> is the value of the unit of measurement associated with the newAttribute data type, if applicable;
• if the current model has a property that is logically related, then the name of that property shall be used as the Note.propertyName value.

In this case, a new <<object>> class (“NewObject”) is added, associated with an existing class. The new <<object>> class has one or more attributes (“newProperty1”, “newProperty2”, etc.), as highlighted in the UML class diagram to the right. The object can be multi-occuring, which is the more general case.

This can be seen as an extension of the MAPC-02, with the difference that several new properties are added, instead of a single property.

The new class and its attributes model information that could not be coded in the existing version. Therefore, no data from the existing version can be mapped into the new object/attributes.

For the backwards mapping, several options are possible: 

• in case the data recipient is not interested in the new information, the new object and its attributes may simply be removed. This option being straightforward, it is not further detailed.
• in case the data recipient needs the new information in structure format, an extension of the previous AIXM version needs to be defined and used. Obviously, this requires a system upgrade. This option also being straightforward, it is not further detailed.
• as an intermediate solution, the new properties may be converted into an annotation. The data will not be suitable for automatic processing, but it might be still useful in case the data recipient is interested to know that the new information exists. In addition, if the new object and its properties are logically related to an existing property, the backwards created Note can be specified as being associated with that existing property.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

Not applicable.

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

From the three backward mapping options discussed above, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:

• Remove the elements that correspond to the new class
• Add an annotation.Note associated with the owner class having

• purpose=“OTHER:BACKWARD_MAPPING”;
• translatedNote.LinguisticNote.note=”newRole[1].newClass.newProperty1: <newProperty1> <uom>; newRole[1].newClass.newProperty2: <newProperty2> <uom>; etc.”, where
• <newProperty#> is the actual value of the newProperty# attribute;
• <uom> is the value of the unit of measurement associated with the newProperty# data type, if applicable;
• “[1]” indicates that this needs to be repeated as many times as necessary to cover all occurrences of the newRole.newObject
• if the current model has a property that is logically related, then the name of that property shall be used as the Note.propertyName value.

This is a variation of the [MAPC-03]. In this situation, the previous AIXM version already had a simple property, but which is deleted and replaced with a series of attributes or with a multi-occuring property, in the form of an associated <<object>>. 

The information contained in the oldProperty can probably be mapped forward, sometimes even 1:1.

Concerning the backward mapping,  a part of the new data can probably be directly mapped to the existing attribute, while the rest needs to be treated as new and dealt with according to one of the options detailed in MAPC-03.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

• Remove the oldProperty
• Add a newRole.NewObject element and convert the value of the oldProperty as appropriate, using the newProperty# attributes

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

From the three backward mapping options discussed for MAPC-03, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into the oldProperty, complemented with a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:

• Remove the elements that correspond to the new class
• If possible, select one of the values from the NewObject.newProperty and convert it into a value that is allowed by the oldProperty
• Add an annotation.Note associated with the owner class having

• purpose=“OTHER:BACKWARD_MAPPING”;
• translatedNote.LinguisticNote.note=”newRole[1].newClass.newProperty1: <newProperty1> <uom>; newRole[1].newClass.newProperty2: <newProperty2> <uom>; etc.”, where
• <newProperty#> is the actual value of the newProperty# attribute;
• <uom> is the value of the unit of measurement associated with the newProperty# data type, if applicable;
• “[1]” indicates that this needs to be repeated as many times as necessary to cover all occurrences of the newRole.newObject
• propertyName=’oldProperty’.

An example of this situation is presented in the UML class diagram to the right.

This is a variation of MAPC-04, as the additional occurrences can be considered as “new” data, while one of them can be directly mapped to the previous single property.

As there is an increase of the number of occurrences of the existing association, all existing data remains valid against the new AIXM version. No forward mapping is necessary.

For the backward mapping, the occurrences that exceed the number allowed by the previous model version are considered “new data”. Depending on the operational needs of the recipient, there are two steps:

• first, decide which occurrences can be preserved as digital data;
• second, decide what to do with the remaining ones - discard, use an extension, create copies of the ‘source class’ for each additional ‘destination class’ or convert into annotations. Annotations will not be suitable for automatic processing, but they might still be useful in case the data recipient is interested to know that the new information exists.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

Not applicable.

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

From the four backward mapping options discussed above, the first two (discard the additional occurrences or use an extension) are straightforward and do not need any further details. The 3rd option (create copies of the ‘source’ for each additional ‘destination’) and the 4th option (backward mapping of the additional occurrences into a Note) are detailed in order to provide complete descriptions of these cases and conversion options. 

3rd option) The following mapping algorithm by multiplying the source class is proposed:

• Identify the occurrences of the safeAltitude that are preserved in the source element (Procedure, in this case);
• For each additional occurrence of the safeAltitude element (Procedure to SafeArea association in this case):
• Remove the safeAltitude element
• Create a copy of the Procedure class, with exactly the same child elements, except for:
• gml:identifier, which gets as value a concatenation of the gml:identifier of the source (Procedure), followed by a separator (“-”) and the gml:identifier of the destination (SafeAltitudeArea) that is mapped;
• safeAltitude, which gets only one occurence (that one that is being mapped);
• Note that the gml:id might also need to be replaced, if the result of the conversion algorithm is an AIXM 5.1(.1) file, to avoid a conflict of XML ID values.

4th option) The following mapping into Note algorithm is proposed:

• Identify the occurrences that are preserved and remove the other occurrences
• Add an annotation.Note associated with the owner class having

• purpose=“OTHER:BACKWARD_MAPPING”;
• translatedNote.LinguisticNote.note=”safeAltitude[1].SafeAltitudeArea: <safeAltitude.xlink:href>; safeAltitude[2].SafeAltitudeArea: <safeAltitude.xlink:href>; etc.”
• “[1]”, “[2]” indicate that this needs to be repeated as many times as necessary to cover all occurrences that are not preserved;
• propertyName=”safeAltitude”.

[MAPC-06] Extended attribute length

The maximum length of an existing attribute is extended, typically by specifying a new data type, as shown in the UML class diagram to the right. This can also occur by changing the limiting pattern of a numerical data type.

All existing data remains valid against the new AIXM version. No forward mapping is necessary.

For the backward mapping, if the actual value fits the old data type, then no action is necessary. Only if the actual value is longer a conversion is necessary. It can be seen as a variation of the mapping case MAPC-02. Several options are possible: 

• in case the data recipient is not interested in the information, the element may simply be removed. This option being straightforward, it is not further detailed.
• in case the data recipient needs the longer element value, several options are possible:
• an extension of the previous AIXM version may be defined and used. Obviously, this requires a system upgrade. This option being straightforward, it is not further detailed.
• trimming  the value is a suitable option when it still gives a meaningful result, such as for a geographical position or a distance that is reduced by a number of decimal places that are well below the required accuracy;
• trimming the value is not a suitable option when it significantly alter its meaning. For example, a place name that is trimmed would result in an unrecognizable name.
• the longer string value may be converted into an annotation (both when trimming is suitable and non-suitable). This will not be suitable for automatic processing, but it might be still useful in case the data recipient is interested to know that the new information exists. The annotation is related to the property concerned.

Forward mapping (from AIXM 5.1.1 to AIXM 5.2)

Not applicable.

Backward mapping (from AIXM 5.2 to AIXM 5.1.1)

From the three backward mapping options discussed above, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:

• If the value of the element is still valid against the previous schema version, do nothing.
• Otherwise:
• Remove the value of the element and insert the following XML attributes
• xsi:nil="true" 
• nilReason="other:invalidValueCopiedAsNote"
• Add an annotation.Note associated with the owner class having

• purpose=“OTHER:BACKWARD_MAPPING”;
• translatedNote.LinguisticNote.note=”<element_value>” (the full content of the longer element string value)
• propertyName=”<element_name>” (the name of the element that has a longer string value)