File Structure

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

...

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 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

...

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

...

The CityType definition uses the CityPropertyGroup and the extension. It extends AbstractAIXMObjectType 
Image Removed 
<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>

...

The City object is then defined as an XSD element of type CityType.
Image Removed 
<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>

...

In the UML below, the NavaidEquipment feature has a relationship to the OrganisationAuthority feature. This relationship contains properties defined in the AuthorityForNavaidEquipment class. 
Image Removed 
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. 
Image Removed 
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. 
Image Removed

...

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.
Image Removed 
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> 

...

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.
!worddav1107a322f49687c3c72f01441b7793fd.png|height=210,width=281!
\\
<<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 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>

(draft text for AIXM 5.2) 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:

...

<annotation>

   <appinfo>deprecated</appinfo>
   <documentation>
       <deprecated>
          <rationale>AIXM-312 - this element is deprecated because… </rationale>
          <replacement>as appropriate – put ‘N/A’ if no replacement is available </replacement>
          <deprecationVersion>5.2</deprecationVersion>
          <deletionVersion>5.3*</deletionVersion>
       </deprecated>
   </documentation>
</annotation>

* If the next version has a different number (for example because a major 6.0 version is published), this element should be interpreted as indicating “next version”.

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.