Purpose and Scope


AIXM was developed to be extensible, allowing greater flexibility for international use, in particular to meet individual needs of the AIXM Community of Interest (COI). The purpose of this section is to provide rules and guidelines for complementing the core AIXM model with extensions and messages that might be necessary in applications used in a specific community of interest.

The Extension Class concept supports the following:

  • extending the core AIXM classes (features and objects) with new attributes or associations;
  • defining new aeronautical information features, which are only relevant for that community.

The Extension Message concept supports the definition of message types that are exchanged in that community. Such messages may have additional properties and might eventually restricting their content to a subset of the AIXM features. They can also include additional feature properties and new features defined through an extension. However, it is not obligatory that specific AIXM messages are defined. Data exchange can be instantiated through standard "feature services". An example is the OGC Web Feature Service (WFS), which enables the direct provision of individual AIXM features or collections of AIXM features. The AIXM core model also provides a "Basic Message", which is simply a collection of any AIXM features. It can be used with both core AIXM features and extensions.

Principles

Some principles that regulate such extensions include:

  • An extension of an existing AIXM feature should remain valid against the definition of the core AIXM XSD element with the same name (for that purpose, the AbstractSomeFeatureExtension element is provided in the core AIXM XSD). A consequence is that it is not possible to extend <<datatype>> classes.
  • Additional feature and objects shall follow the core AIXM modelling conventions (stereotypes, naming, data types, etc.).

Important Note

It is under the responsibility of the developers of an extension to ensure that it does not duplicate features and properties that already exist in the core model. Developers of extensions are strongly encouraged to share their work with the global AIXM community. For this purpose, the extension schema can be made available through the Extensions space

Usage of extensions

Use cases that are supported

  • single feature with extension properties
  • single extension feature
  • AIXM Basic Message with extension properties and extension features

When the AIXM Basic Message is used with extensions, it DOES NOT NEED to be re-defined in order to include the features defined in an extension. That's because the AIXM_Basic Message is defined having as content any AbstractAIXMFeature. Therefore, it is sufficient that an extension feature (such as Event) is declared in its own schema as being in the substitution group for AbstractAIXMFeature and it can be used a BasicMessage/hasMember child element.

For each specific use case, both the UML model conventions and the XML schema mapping are provided in the following section.

  • No labels