Page Comparison

Description

The discrepancy between the AIXM 5.1(.1) UML model and the XML schema on the multiplicity of the SafeAltitudeArea in the association with Procedure is corrected to allow 0..* in both.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-103

A bug was discovered in the script used to generate the XML schema from the Rational Rose UML model. The script did not support associations towards features that have a cardinality different than 0..1 or 0..*. A cardinality such as 0..2 was wrongly generated in the XSD schema without any “maxoccurs” attribute, which practically makes it a single occurrence property.

The element affected by this bug is the safeAltitude property of the Procedure (i.e. StandardInstrumentDeparture, StandardInstrumentArrival and InstrumentApproachProcedure) which represents the association with the SafeAltitudeArea feature.

There exist examples of procedures that have both MSA and ESA specified. Therefore, the multiplicity of the association is still justified to be more than one, as it was already the case in the AIXM 5.1 UML model. In order to avoid a unique case in the whole model where the maximum multiplicity is specified to something different than 1 or n, this maximum of “2” is modified to a maximum of “n”. This will ensure that the current UML to XSD script generates it correctly.

Impact assessment

There is no impact on existing implementations as the current AIXM 5.1(.1) data remains fully valid against AIXM 5.2.

When receiving data from AIXM 5.2 implementations that actually have more than one occurence of the safeAltitude element, current AIXM 5.1(.1) systems will have to apply the mapping rules specified further in this document.

Note: As the script used for the application/xml schema is also used for generating extension schemas, cardinalities for associations towards features that are different from 0..1 or 0..* shall not be used. If it is envisaged that more than one instances of an association might occur, it is advised to model it with a cardinality 0..*. Never use a specific number such as 0..2, 0..3, etc.

Change Proposal details

The following change is done in the AIXM UML mode, on the class Procedure

• the multiplicity of the SafeAltitudeArea in the association with Procedure is changed to 0..* in the UML model (instead of 0..2).

The UML class diagram below shows the modified association multiplicity on the SafeAltitudeArea side.

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

NIL (Not applicable).

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

[MAPC-05] From the three backward mapping options available in this case, the first two (discard the additional occurrences or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping of the additional occurrences 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:

For each SID, STAR or InstrumentApproachProcedure that has two or more safeAltitude elements:

• Preserve the safeAltitude element that refers  to a SafeAltitudeArea having safeAreaType equal-to ‘MSA’; If it does not exist or if more than one exists, then do not preserve anything;
• For each of the safeAltitude element that is not preserved according to the rule above, remove the element and add an annotationNote with:
• propertyName=safeAltitude
• 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;

Mapping example

(Note: for mapping test data see: https://github.com/aixm/mapping_52_511/tree/master/AIXM-142)