The AIXM Temporality Concept explains that all feature properties can change in time. Only the gml:identifier property is considered to have the same value for the complete duration of the feature lifetime. The Feature Identification and Reference documentexplains the different options that exist for the value of the gml:identifier and the possibilities for the encoding of feature references (associations). From an international perspective, with very few exceptions related to cross-border data, each aeronautical data feature contained in the AIS Data Set is issued under the authority of a State. The State is the single authoritative data source and can therefore allocate stable UUID values to each feature and make this information available to the neighboring States for cross-border coordination.

Rule

Each AIXM feature included in an AIS Data Sets shall have a non-empty gml:identifier.

Rule

The gml:identifier shall be a UUID value, as defined in the AIXM Feature Identification and Reference document.

Rule

The UUID values shall be generated with a compliant Version 4 UUID generator.

Important Note

It is important to use a true UUID version 4 generator! Do not create and do not use pseudo-UUID values (a string of characters that looks like a UUID and which might even comply with the UUID version 4 syntax, but that was not generated with a proper UUID version 4 generator)!

The consequence of using pseudo-UUID values could be for a data user to be confronted with two different feature instances that have the same gml:identifier value, while they are in reality different aeronautical information features. Such errors are easier to detect when the two instances are of different kind (for example, a Runway and a Navaid), but more difficult when the two instances happen to be of the same kind (such as two Airspace).

In order to prevent problems that could occur from the use of pseudo-UUID, the validation rules for the AIS Data set include checks for the plausibility of the associations. For example, a check that the xlink:href element of a Runway.associatedAirportHeliport property actually resolves into one and only one AirportHeliport and not into something else). However, resolving such conflicts might take a significant amount of energy and time.

It is not technically possible to verify that a UUID was actually generated with a correct UUID version 4 algorithm. Therefore, it is the responsibility of the data providers to make sure that UUID values are correctly generated and are not altered by manual intervention.

Rule

Abstract references (by gml:identifier), as defined in the document, shall be used whenever the target record is not contained in the same data set.

Rule

Either abstract references (by gml:identifier) or internal references (by gml:id), as defined in the document, shall be used whenever the target record is contained in the same data set.

AIXM uses extensively empty elements with an xlink:href attribute in order to code associations between features. According to the XML schema specification, an xsi:nil='true' attribute can be used in order to explicitly indicate that the element is empty. The xsi:nil applies only to element values, and not to attribute values. The XSD standard allows for an element to have at the same time an xsi:nil="true" attribute and other attributes. The presence of both xsi:nil='true' and of the xlink:href attribute with a value can lead to confusions. Some XML implementations (such as the default XML Serializer of .Net) ignore everything if an element has an xsi:nil="true" attribute. That means any additional information that would be present in other attributes is not parsed and not even accessible and/or visible.

As there is no operational need for allowing an element in AIXM to have both xsi:nil=”true” and an xlink:href attribute value, in the interest of a wider interoperability, the use of xsi:nil=”true” is forbidden in this case.

Rule

An element that has an assigned ‘xlink:href’ attribute value shall not have a xsi:nil="true".

References

Browser not supported