Mapping to the AIXM XML Schema

AIXM - core XSD files

The core AIXM exchange format is composed of three main files:

• AIXM_AbstractGML_ObjectTypes.xsd: the file references the ISO19139 Metadata Schema and defines the base AIXM Feature/Object constructs
  • AbstractAIXMFeatureType / AbstractAIXMFeature
  • AbstractAIXMTimesliceType / AbstractAIXMTimeslice
  • AbstractAIXMObjectType
  • AbstractAIXMPropertyType, which defines the nilReason for all the AIXM complex properties
• AIXM_Datatypes.xsd: this file contains the XML representation of all the data types defined in the AIXM UML model.
• AIXM_Features.xsd: this file contains the XML representation of all the AIXM features with all their properties (simple and complex).

The chapters here after specify the rules that govern the mapping between the AIXM UML model and the AIXM XML Schema.

AIXM is GML

The AIXM exchange model is an XML exchange standard based on a subset of the Geography Markup Language (GML). Essentially:

• AIXM Features are GML features;
• AIXM Objects are GML objects;
• AIXM follows the GML object-property concept.

The GML Object-Property Model

The GML object-property model explains some of the complexity of the AIXM UML to XSD mapping. It means that no GML object may appear as the immediate child of a GML object. Consequently, no element may be both a GML object and a GML property. 
The object-property model prohibits the encoding of an object directly inside a feature, e.g.
 
<AirportHeliport> <!-- feature --> > <ElevatedPoint> <!- object --> 
 
The direction of the association arrow from the UML diagrams (the navigability) dictates which of the two association partners has the property that associates the other. 
In the AIXM XML Schema, the object-property model is encoded by declaring a type and then assigning properties (attributes and relationships) to that type. The type defines the object. 

Mapping Inheritance

Within the AIXM XML Schema, inheritance implies two characteristics:

1. Substitutability. The more general feature or object can be substituted by a specialization. In the XML schema this is supported using substitution groups.
2. Property inheritance. The specialized feature inherits all of the properties of the more general feature. In the XML schema including the properties of the general class into the specialized class supports this.

Mapping Name of Classes

The UML class name is used for the element names in the XML Schema.

Mapping Features

For each AIXM Feature in the UML, the following XML schema entities are created:
The direction in which the different types and elements are used in the schema definition
(e.g. Feature uses FeatureType)* FeaturePropertyType

• Feature
• FeatureType
• FeatureTimeSlicePropertyType
• FeatureTimeSlice.
• FeatureTimeSliceType
• FeaturePropertyGroup
• AbstractFeatureExtension

An Example Mapping

The Runway feature (shown below) will be used to illustrate the mapping. The example will concentrate on the properties (shown as attributes). 

RunwayPropertyGroup

An XML Schema (XSD) group is generated for each feature containing all of the properties (attributes and relationships) of the feature. 
The order in which the chilled elements of the group are declared is the following: 

1. (if applicable) in the case of derived classes only, the property group of the super class is inserted first;
2. then, all the elements that correspond to class attributes, in the order that they appear in the UML class diagram
3. then, all the elements that correspond to association role names, in random order;
4. last the "annotation" property – note that for derived classes this property is only defined in the super class, therefore it will appear in the property group of the super class.

Below is an example of the RunwayPropertyGroup in graphic form and as an extract from the XSD. It shows clearly how the attributes are mapped from the UML to the XSD and how the relationship 'associatedAirportHeliport' is created. 

<group name="RunwayPropertyGroup">
<sequence>
<element name="designator" type="aixm:TextDesignatorType" nillable="true" minOccurs="0"/>
<element name="type" type="aixm:CodeRunwayType" nillable="true" minOccurs="0"/>
<element name="nominalLength" type="aixm:ValDistanceType" nillable="true" minOccurs="0"/>
<element name="lengthAccuracy" type="aixm:ValDistanceType" nillable="true" minOccurs="0"/>
...
<element name="associatedAirportHeliport" type="aixm:AirportHeliportPropertyType" nillable="true" minOccurs="0"/>
...
<element name="areaContaminant" type="aixm: RunwayContaminationPropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
<element name="annotation" type="aixm:NotePropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</group>

RunwayTimeSliceType

The properties of a feature or the target of any feature relationship can change within the lifetime of the feature. This temporality can be expressed in GML by using dynamic features and feature collections. The TimeSlice property of a dynamic feature contains one or more Feature TimeSlices that capture the evolution of the feature over time. A gml:TimeSlice object contains the dynamic properties of the feature. 
For each feature a TimeSlice property is created that contains an array of feature TimeSlice objects. This example shows the RunwayTimeSliceType encapsulating all of the Runway properties (RunwayPropertyGroup created above) that change over time.
 
<complexType name="RunwayTimeSliceType">
<complexContent>
<extension base="aixm:AbstractAIXMTimeSliceType">
<sequence>
<group ref="aixm:RunwayPropertyGroup"/>
<element name="extension" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element ref="aixm:AbstractRunwayExtension"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>

RunwayTimeSlice

The FeatureTimeSlice object is of type FeatureTimeSliceType. Continuing the example, the RunwayTimeSlice element is of type RunwayTimeSliceType. 
 
<element name="RunwayTimeSlice" type="aixm:RunwayTimeSliceType" substitutionGroup="gml:AbstractTimeSlice"/> 

RunwayTimeSlicePropertyType

A GML property type containing a FeatureTimeSlice objects is created.
 

<complexType name="RunwayTimeSlicePropertyType">
<sequence>
<element ref="aixm:RunwayTimeSlice"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>

RunwayType

Continuing with the object-property model, the Runway feature type is created extending the AbstractAIXMFeatureType with the RunwayTimeSlice object created above. 
 
<complexType name="RunwayType">
<complexContent>
<extension base="aixm:AbstractAIXMFeatureType">
<sequence>
<element name="timeSlice" type="aixm:RunwayTimeSlicePropertyType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>

Runway

The Runway feature is then defined by the RunwayType. 
 
<element name="Runway" type="aixm:RunwayType" substitutionGroup="aixm:AbstractAIXMFeature">
<annotation>
<appinfo>RWY</appinfo>
<appinfo><gml:description>A defined rectangular area on a land aerodrome/heliport prepared for the landing and take-off of aircraft. Note: this includes the concept of Final Approach and Take-Off Area (FATO) for helicopters.</gml:description></appinfo>
</annotation>
</element> 

RunwayPropertyType

When a property of a feature is a relationship, the relationship must be associated to another feature or object. This is done through the creation of the FeaturePropertyType, in this case, the RunwayPropertyType. 
In AIXM, when the relationship or association points to another feature, the feature is referenced using the xlink:href attribute (it's always a "remote" encoding). When the relationship points to an object, the object is included inside the parent. (Objects cannot exist without the parent.) Since a Runway is a feature the RunwayPropertyType is created with the attribute xlink:href . 
 
<complexType name="RunwayPropertyType">
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
<attributeGroup ref="gml:AssociationAttributeGroup"/>
</complexType>

RunwayExtension

All Features and Objects can be extended. A relationship is created with an abstract XML element that acts as the root for all extensions. Below is an example of the extension for the Runway feature. The AbstractRunwayExtension element uses the AbstractExtensionType as shown below. 
 
<element name="AbstractRunwayExtension" type="aixm:AbstractExtensionType" abstract="true" substitutionGroup="aixm:AbstractExtension"/> 

Mapping Objects

AIXM objects are encoded as GML objects. For the most part, the XML schema entities are created in the same way as for Features, following the object-property model. However it is important to remember that AIXM objects do not exist outside of a feature and are therefore part of the feature timeslice. TimeSlice types and elements are not created for objects. 
For each AIXM Object the following XML schema entities are created: 

• ObjectPropertyGroup
• Object
• ObjectType
• ObjectPropertyType
• AbstractObjectExtension

ObjectType is complex type which extends AbstracAIXMObjectType. 
<complexType name="NavaidEquipmentDistanceType">
<complexContent>
<extension base="aixm:AbstractAIXMObjectType">
<sequence>
<group ref="aixm:NavaidEquipmentDistancePropertyGroup"/>
<element name="extension" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element ref="aixm:AbstractNavaidEquipmentDistanceExtension"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType> 

ObjectPropertyType type is a complex type which extends aixm:AbstractAIXMPropertyType. 
<complexType name="NavaidEquipmentDistancePropertyType">
<complexContent>
<extension base="aixm:AbstractAIXMPropertyType">
<sequence>
<element ref="aixm:NavaidEquipmentDistance"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</extension>
</complexContent>
</complexType> 

An Example Mapping

The example will use the City object illustrated below. The object represents the town that is served by an AirportHeliport. 

AbstractCityExtension

An abstract XML element acts as the root for all extension to the City object. Object extensions are defined in the same way as Feature extensions. 
 

<element name="AbstractCityExtension" type="aixm:AbstractExtensionType" abstract="true" substitutionGroup="aixm:AbstractExtension"/>

CityPropertyGroup

An XSD group containing the properties of the City object is created, again similar to Features. 
 
<group name="CityPropertyGroup">
<sequence>
<element name="name" type="aixm:TextNameType" nillable="true" minOccurs="0">
<annotation>
<appinfo>AIXM 4.5</appinfo>
<appinfo><gml:description>The full free text name of the city or town the aerodrome/heliport is serving.
</gml:description></appinfo>
</annotation>
</element>
<element name="annotation" type="aixm:NotePropertyType" nillable="true" minOccurs="0" maxOccurs="unbounded">
</element>
</sequence>
</group>

CityType

The CityType definition uses the CityPropertyGroup and the extension. It extends AbstractAIXMObjectType 
 
<complexType name="CityType">
<complexContent>
<extension base="aixm:AbstractAIXMObjectType">
<sequence>
<group ref="aixm:CityPropertyGroup"/>
<element name="extension" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element ref="aixm:AbstractCityExtension"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>

City

The City object is then defined as an XSD element of type CityType.
 
<element name="City" type="aixm:CityType">
<annotation>
<appinfo><gml:description>A city or location that may be served by an airport/heliport.</gml:description></appinfo>
</annotation>
</element>

CityPropertyType

An XSD complex type representing a GML property type is created. A Feature uses this element to include the City object rather than reference it (using xlink:href) because object does not exist without the parent. 
 
<complexType name="CityPropertyType">
<complexContent>
<extension base="aixm:AbstractAIXMObjectType">
<sequence>
<element ref="aixm:City"/>
</sequence>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</extension>
</complexContent>
</complexType>

Mapping Choices

Classes marked with the stereotype <<choice>> do not appear in the XML Schema. Instead, the choice of elements is created. 
 
The name of the element is the concatenation of the role of the <<choice>> class with the role of the target class of each choice branch, separated by "_". 
<group name="HoldingPatternPropertyGroup">
<sequence>
............
<element name="nonStandardHolding" type="aixm:CodeYesNoType" nillable="true" minOccurs="0">
<annotation>
<appinfo>
<gml:description>ndicates whether the HoldingPattern is non-standard, for example because it uses left-hand turns.</gml:description>
</appinfo>
</annotation>
</element>
<choice>
<element name="outboundLegSpan_endTime" type="aixm:HoldingPatternDurationPropertyType" nillable="true" minOccurs="0">
<annotation>
<appinfo>
<gml:description>Span is timing</gml:description>
</appinfo>
</annotation>
</element>
<element name="outboundLegSpan_endDistance" type="aixm:HoldingPatternDistancePropertyType" nillable="true" minOccurs="0">
<annotation>
<appinfo>
<gml:description>span is length</gml:description>
</appinfo>
</annotation>
</element>
<element name="outboundLegSpan_endPoint" type="aixm:SegmentPointPropertyType" nillable="true" minOccurs="0">
<annotation>
<appinfo>
<gml:description>The second waypoint of a two point holding, used to define the end of the outbound leg.</gml:description>
</appinfo>
</annotation>
</element>
</choice>
............
</sequence>
</group> 

Mapping Relationships to Objects

Relationships are encoded by creating an XML element with the same name as the role name on the UML model. It is of type ObjectPropertyType. 

 
In this example, the SurfaceCharacterisitcs object is a property of the Runway. The "surfaceProperties" property of the Runway is defined as being of type SurfaceCharacteristicsPropertyType. 

 
<element name="surfaceProperties" type="aixm:SurfaceCharacteristicsPropertyType" minOccurs="0"/> 

Mapping Associations with Association Classes

In the UML below, the NavaidEquipment feature has a relationship to the OrganisationAuthority feature. This relationship contains properties defined in the AuthorityForNavaidEquipment class. 
 
When mapping this in XSD, an 'authorityForNavaidEquipment' property is created in the NavaidEquipment feature as shown below. The name of this property is automatically derived from the name of the association class, by conversion to lowerCamelCase style. The direction of the arrow is important. If the direction would have been to the NavaidEquipment, the property would have been created in the OrganisationAuthority feature. 
 
A second step is then required to complete the XSD. In this case an element named 'theOrganisationAuthority' is added in the definition of the AuthorityForNavaidEquipmentPropertyGroup, based on the role of the OrganisationAuthority class in this association. 

Mapping Relationships to Features

In AIXM, Relationships to features are described by reference using xlink:href. The UML role name is used for the XML element name and the XML element is of type FeaturePropertyType. 
 

 

 Mapping Data Types

<<codelist>>

Codelists are given by the stereotype <<codelist>>. As it can be seen from the diagram elow, for each <<codelist>> type, there also is a <<datatype>> class, which defines the nilReason attribute.
 
First, the <<codelist>> class is converted into a simpleType in the XSD: 
<simpleType name="CodeAircraftEngineBaseType">
<annotation>
<appinfo><gml:description>A code indicating the type of aircraft engine (for example, jet, piston, turbo).</gml:description></appinfo>
</annotation>
<union>
<simpleType>
<restriction base="xsd:string">
<enumeration value="JET">
<annotation>
<appinfo><gml:description>Jet Engine</gml:description></appinfo>
</annotation>
</enumeration>
<enumeration value="PISTON">
<annotation>
<appinfo><gml:description>Piston Engine</gml:description></appinfo>
</annotation>
</enumeration>
<enumeration value="TURBOPROP">
<annotation>
<appinfo><gml:description>Turbo Propeller Engine</gml:description></appinfo>
</annotation>
</enumeration>
<enumeration value="ALL">
<annotation>
<appinfo><gml:description>All aircraft engine types.</gml:description></appinfo>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType>
<restriction base="string">
<pattern value="OTHER(\w|_){1,58})?"/>
</restriction>
</simpleType>
</union>
</simpleType> 
Note that the simple data types is declared as a union between the enumerated values declared in the UML model (with the exception of the value "OTHER") and a string with the pattern "OTHER(\w|_){1,58})?". This enables <<codelist>> data types to include values that are not supported by the enumeration list. For example, an electric engine type could be encoded as "OTHER:ELECTRIC". 
In addition, a complex type is defined, including the declaration of the nilReason attribute: 
<complexType name="CodeAircraftEngineType">
<simpleContent>
<extension base="aixm:CodeAircraftEngineBaseType">
<attribute name="nilReason" type="gml:NilReasonEnumeration"/>
</extension>
</simpleContent>
</complexType> 

<<datatype>> - default case

As for <<codeList>>, the mapping of <<datatype>> used to type simple properties (see ‎2.7.1.1) consists of two steps. 
The first step is the creation of the simpleType corresponding to the BaseType. 
<simpleType name="DateBaseType">
<restriction base="xsd:date">
</restriction>
</simpleType> 

The second step is the creation of the complexType which defines the attribute nilReason.
<complexType name="DateType">
<simpleContent>
<extension base="aixm:DateBaseType">
<attribute name="nilReason" type="gml:NilReasonEnumeration "/>
</extension>
</simpleContent>
</complexType> 

<<datatype>> with Unit of Measurement

A Unit of measurement (UOM) exists for many data types that take numerical values. This has been modelled as a uom attribute in the <<datatype>> class. 
 
The XSD mapping of uom types follows the same rules as for any other <<codelist>>, except that no complex type is required with the nilReason. 
<simpleType name="UomDepthType">
<union>
<simpleType>
<restriction base="xsd:string">
<enumeration value="MM">
</enumeration>
<enumeration value="CM">
</enumeration>
<enumeration value="IN">
</enumeration>
<enumeration value="FT">
</enumeration>
</restriction>
</simpleType>
<simpleType>
<restriction base="string">
<pattern value="OTHER:\w{2,58}"/>
</restriction>
</simpleType>
</union>
</simpleType> 

In a second step, the class ValDepthBaseType is generated as a simple type, as described in ‎4.11.2. 
<simpleType name="ValDepthBaseType">
<restriction base="xsd:decimal"/>
</simpleType> 
Then, the uom attribute is added to the complexType ValDepthType, after the definition of nilReason attribute. 
 
<complexType name="ValDepthType">
<simpleContent>
<extension base="aixm:ValDepthBaseType">
<attribute name="nilReason" type="gml:NilReasonEnumeration"/>
<attribute name="uom" type="aixm:UomDepthType" use="required"/>
</extension>
</simpleContent>
</complexType> 

Particular cases

<<datatype>> with no BaseType

The 5 data types listed in ‎2.7.1.1 map directly to the built-in datatypes defined by the XML schema specification. The default datatypes are string, float, double, etc, which are considered simpleTypes.
The AlphaType acts as a convenient example.
Unable to render embedded object: File (worddav1107a322f49687c3c72f01441b7793fd.png) not found.
<<span style="color: #000080"><strong>simpleType</strong></span> name="<span style="color: #000080"><strong>AlphaType</strong></span>">
<restriction base="xsd:<span style="color: #000080"><strong>string</strong></span>">
<pattern value="[A-Z]*"/>
</restriction>
</simpleType>

<<datatype>> XHTMLBaseType

<<datatype>> XHTMLBaseType represents a structured XHTML document compliant with http://www.w3.org/1999/xhtml. It should be mapped as follows in XML: 
<complexType name="XHTMLBaseType">
<sequence>
<any namespace="http://www.w3.org/1999/xhtml" minOccurs="1" maxOccurs="unbounded" processContents="skip"/>
</sequence>
</complexType>

How to define specific AIXM messages

 Overview

The message package is used to generate an XML Schema for request and response messages. Below is an example of the TestBasicMessage. This message includes the extensions described previously even though they do not appear in the diagram.
A Message is modelled in UML using the class object with a stereotype <<message>>. In this example the message is a limited collection of AIXM features with extensions. This is modelled by relating the collection of features; <<collectionMemberChoice>> to the message through the relationship "hasMember".

 XML Schema Generation

Follow the procedures outlined in section 2.2.2.2.

XML Schema Output

Classes with the stereotype of <<message>> following the AIXM feature collection response generates four related elements for that class.

• <classname>MessageMemberPropertyGroup
• <classname>MessagePropertyGroup
• <classname>MessageType
• <classname>Message

The <classname>MessagememberPropertyGroup is generated as a XMLSchema <complexType>, which extends gml:AbstractFeatureMemberType, and includes a <choice> between the all the features it is pointing to.

The <classname>MessagePropertyGroup is generated as a XMLSchema <group>, which contains the properties (elements and relationships) of the Message.
 
The <classname>MessageType element is generated as a XMLSchema <complexType.> and extends base type aixm:AbstractAIXMMessageType.
 
The <classname>Message element is generated as a XMLSchema <element>. The associations are treated as objects. They are included in the schema.  

Deprecation of an element inside the AIXM XSD Schema

For each XML property and type deprecated in the UML model, the generated XSD schema will include deprecation information under the XML annotation tag, as shown below:

Particular case : the association to a Choice.

An association to a Choice does not result in a single element inside the XSD, but is "exploded" into as many elements as there is choices in the model. When it is the case, the deprecation annotation will be repeated in all the “exploded” elements inside the XSD.