...

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

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