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 "TestExt Features" sub-package contains the extensions to AIXM core <<features>> and/or <<objects>>;
  • if the extension requires new data types, then a second sub-package ("TestExt Data Types" in this case) is created, containing any new data types and codelists needed;
  • another sub-package that may be needed is the message package ("TestExt Basic Message" in this example). Multiple sub-packages may be required based on the number of different message schemes needed.

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="" schemaLocation=""/>
<import namespace="" schemaLocation=""/>

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="" 
elementFormDefault="qualified" attributeFormDefault="unqualified" version="5.1.1.a">

<import namespace="" schemaLocation=""/>
<import namespace="" schemaLocation=""/>
<import namespace="" schemaLocation="../../AIXM_Features.xsd"/>
<include schemaLocation="./TestExt_DataTypes.xsd"/>
  • No labels