AIXM Schema Merger



The Aeronautical Information Exchange Model (AIXM) has a specific way of adding information to core schema classes that is different to how it is usually done in UML and in ISO application schema. Where usually information is added through subtyping, AIXM has the concept of extensions. An extension schema is a schema that:

  • Can define <<extension>> classes that extend:
    • either a specific feature or object type
    • or all feature types
  • Can define <<codelist>> classes that extend code lists from the core schema
  • Can define new code lists as well as feature and object types

The objective of this approach is described in the AIXM Application Schema Generation document, section 1.3, as follows:

“The core AIXM model provides the definition of standardised aeronautical information features. In order to use AIXM for a specific application, a Community of Interest (COI) will have to agree upon how instances of AIXM features are to be exchanged and communicated in the community. […]

In the definition of the AIXM Application Schema, the COI might also want to extend the core AIXM with additional properties and features. 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. Only <<codelist>> may be extended.
  • An additional feature and objects shall follow the core AIXM modelling conventions (stereotypes, naming, data types, etc.)”

A consequence of this approach is that actual AIXM data can contain information that is specified by multiple extensions, and that an AIXM processor is able to ignore unknown extensions to core AIXM features.

With the AIXM extension mechanism, AIXM feature and object types conceptually own all the properties that are added to them via <<extension>> types.

This transformation merges AIXM extension schemas and the core schema. The result of the merging process is a single schema that contains the feature and object types declared in all schemas, where properties added via extensions have been copied to the relevant types. Merging also adds time slices to AIXM feature types. More specifically, time slice types are defined for each AIXM feature type, with the properties that belong to the feature type.

While merging the schemas, ShapeChange keeps track of XML Schema information – like the target namespace and the preferred namespace prefix – for extension schema elements. This is necessary for example to create correct XPath expressions and namespace declarations when creating Schematron code.


The following sections specifiy the configuration options for this transformation.


In order for this transformation to work, the input model must fulfill the following conditions:

  • the input parameter ‘isAIXM’ must be set to ‘true’
  • the core AIXM schema must have a target namespace – either declared via the according tagged value or using a PackageInfo element in the input configuration; the target namespace shall match the value of the parameter ‘coreSchemaTargetNamespace’ (see further below)
  • the core AIXM schema as well as relevant extension schemas must be contained in the model and must be selected for processing (if the input parameters ‘appSchemaName’, ‘appSchemaNameRegex’ or ‘appSchemaNamespaceRegex’ are used, they must include these schemas)


The class for this transformer implementation is de.interactive_instruments.ShapeChange.Transformation.AIXM.AIXMSchemaMerger.


The following parameters are supported by this transformation.

Parameter Name Applies to rule Required / Optional Type Default Value Explanation
coreSchemaTargetNamespace (none – default behavior) Optional String The target namespace of the core AIXM schema.


At the moment no specific rules are defined for this transformation.

Map Entries

At the moment no map entries are defined for this transformation.

Sample Configuration

  input="INPUT" id="step1" mode="enabled">
    <ProcessParameter name="coreSchemaTargetNamespace"
      value="" />