File Structure

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

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

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.