...

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

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

<<datatype>> - default case

...

<<datatype>> with Unit of Measurement

...

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

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