Defining the extension in UML

UML Package for Extensions

To extend AIXM, a new package (eventually including sub-packages) must be created under the AIXM Application Schemes package. This package will contain all the information you need for the extension.

The building of an extension and the generation of the supporting XML Schema is illustrated using a fictitious "Test Extension". The Sparx EA file that includes the core AIXM 5.1.1 model and this sample extension is available on GitHub: Test Extension.

Package Structure

Different types of sub-packages are used to control the generation of appropriate XML schemas (XSD). The example on the right shows the package of the fictitious "TestExtension" used as example, comprising the three sub-packages

The following possibilities for extensions may be applied:

1. the most common one - will have the feature package and the data type package. No new message type is created because either the AIXM-BasicMessage is used or because the data is made available through a 'feature service' that does not require a message type.
2. feature package only - as a simpler variation of the case a) - no new data types are needed, just additional attributes/associations are needed.
3. message package only - when you need to develop a specific message type, for a subset of the existing AIXM features. No new features or data types are created
4. all packages
5. only data types package, when it is re-used by other extension packages.

Package Specifications and Namespaces

There are several properties that need to be set at package level so the corresponding XSD generation script can generate the namespaces correctly. Below is an example of how these attributes are set for the TestExtFeatures sub-package. In order to define them, please use the "add new tag" menu and its dropdown list. The targetNamespace and targetNamespacePrefix property values are to be determined by the community of interest for which the extension is developed. 

Additionally, some custom "AIXM" properties need to be defined, as indicated in the screenshot below. The generateFileName property indicates that file name of the XSD that is output from the package. The fileLocation property defines the relative location where the extension will be stored (this property allows the script to correctly generate the reverse links to the AIXM XSD files inside the extension XSD files. e.g. "../../AIXM_Features.xsd")

Finally, in order to correctly generate the necessary import/include statements, the Links between the packages have to be specified, as shown in this example for the TestExtFeatures package:

This dependency is also visible in the features package properties: 

Note that the import statements for the gml and xlink namespaces are generated by default. The following import statements is included by default in any extension file:

<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.w3.org/1999/xlink.xsd"/>

The eventual import of the AIXM namespace has to be declared explicitly, as a package import (as shown on the previous package diagram).
The following was generated for the fictitious Extension Application Schema package. The extension data types include statement is generated based on the schema dependency.

<schema xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:aixm="http://www.aixm.aero/schema/5.1.1" 
xmlns:testext="http://www.aixm.aero/schema/5.1.1/extensions/test" 
xmlns:gml="http://www.opengis.net/gml/3.2" 
xmlns:xlink="http://www.w3.org/1999/xlink" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.aixm.aero/schema/5.1.1/extensions/test" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="5.1.1.a">

<import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
<import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.w3.org/1999/xlink.xsd"/>
<import namespace="http://www.aixm.aero/schema/5.1.1" schemaLocation="../../AIXM_Features.xsd"/>
<include schemaLocation="./TestExt_DataTypes.xsd"/>

Features Extension Sub-package

Overview

An AIXM class with <<feature>> or <<object>> stereotype may be extended by creating a class with the same name as the core AIXM class and giving it a stereotype <<extension>>. This new class can contain:

• New attributes
• New associations.

Some rules that apply to new extension classes are:

• The extension class stereotype must be <<extension>>;
• The extension class name for the extension must match the class that is extended;
• The extension class must be a specialized class extending the matching base class, i.e. if a core AIXM class is involved, the navigability of the association should always be from the <<extension>> class towards the core AIXM class.
• The extension class attributes are added to the extension class the same as they would be a regular AIXM class (Data Types are discussed later in this document).

The example to the right shows the modeling convention used to extend the core AIXM AirspaceActivation feature. 
The example adds a new attribute to AirspaceActivation and a new relationship to a new object called TestObject.
In addition, it is possible in extensions to create totally new classes (features and objects), that do not extend existing AIXM Core classes.
The only rule is to follow the AIXM UML modeling conventions described at the beginning of the document. This will enable the EA export script to correctly generate the XML elements for these new classes. This situation is not described in detail in this document because it does not require any special action. Just follow the UML modeling conventions.
Associations can be created between new features or objects and AIXM Core features or objects as depicted below in the association between the RouteAvailability and the Airspace feature. The new association should be created in the Application Schema package and towards the AIXM Core Feature rather than an extension (if present). This action ensures the relationship is represented properly in the XML Schema.

Concerning annotations/remarks, the core AIXM model includes as dedicated <<object>> named Note. This is associated with all the classes defined in the AIXM model. It is recommended that each <<object>> or <<feature>> class created in an extension is also associated with the Note class of AIXM. This gives the possibility to add remarks, descriptions and other such free text notes in relation of extended features or properties.
Attention: it does not make sense to add the association to Note from the <<extension>> classes! That's because an <<extension>> class does not create a new feature or object. It just adds properties to an existing AIXM class, which already has the association to Note. The XSD generation script will even ignore such associations.