Data Model Project

Enterprise Architect Customization

of Model Transformation and Code Generation

Last Update: 29-Jan-2019

Document Status Live

DRAFT V0.95

For further information and updates please contact Jean-Christophe Cornu ([email protected]) at IATA Airline
Industry Data Model Secretariat ([email protected])
.
Table of Contents
1 INTRODUCTION ...............................................................................................................................4
1.1 PURPOSE ................................................................................................................................... 4
1.2 AUDIENCE .................................................................................................................................. 4
1.3 APPROACH ................................................................................................................................. 5
2 PREREQUISITES ..............................................................................................................................5
3 HIGH LEVEL MAPPINGS .................................................................................................................6
3.1 OVERALL MAPPING DIAGRAM ...................................................................................................... 6
3.2 CLASS AND ATTRIBUTE MAPPINGS FOR ENUMS AND BIES........................................................... 7
4 PRIM ..................................................................................................................................................8
5 ENUMERATION – WITHOUT VALUES..........................................................................................10
5.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 10
5.2 CODE GENERATION MAPPING .................................................................................................... 11
5.3 SAMPLE XML CODE ................................................................................................................. 11
6 ENUMERATION – WITH VALUES .................................................................................................12
6.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 12
6.2 CODE GENERATION MAPPING .................................................................................................... 13
6.3 SAMPLE XML CODE ................................................................................................................. 13
7 BUSINESS DATA TYPES (BDT) WITHOUT SUPPLEMENTARY ATTRIBUTES .........................15
7.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 15
7.2 CODE GENERATION MAPPING .................................................................................................... 16
7.3 SAMPLE XML CODE ................................................................................................................. 16
8 BUSINESS DATA TYPES (BDT) WITH SUPPLEMENTARY ATTRIBUTES ................................18
8.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 18
8.2 CODE GENERATION MAPPING .................................................................................................... 19
8.3 SAMPLE XML CODE ................................................................................................................. 19
9 ABIE.................................................................................................................................................21
9.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 21
9.2 CODE GENERATION MAPPING .................................................................................................... 21
9.3 SAMPLE XML CODE ................................................................................................................. 21
10 BBIE.................................................................................................................................................23
10.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 23
10.2 CODE GENERATION MAPPING .................................................................................................... 24
10.3 SAMPLE XML CODE ................................................................................................................. 24
11 IDENTIFIER (ID) COMPLEX TYPE GENERATION .......................................................................26
12 ASBIE ..............................................................................................................................................27
12.1 DETAILED PROPERTIES TRANSFORMATION MAPPING.................................................................. 29
12.2 CODE GENERATION MAPPING .................................................................................................... 29
12.3 SAMPLE XML CODE ................................................................................................................. 30
13 SCHEMA VERSION GENERATION ...............................................................................................31
14 TEST CASES FOR MODEL TRANSFORMATION (I3 TO I4 AND T3 TO T4) ..............................32
15 ANNEX ............................................................................................................................................41
15.1 UN/CEFACT EXPERTS CONTACTED ......................................................................................... 41

Page 2 of 41
Revision History
Version Date Name Description of change
0.1 1 Oct 2014 Peter Neumann Initial draft of document
0.2 10 Oct 2014 Peter Neumann Chapter 2 to 9
0.3 17 Oct 2014 Peter Neumann Chapter 4,5,6,8,9
0.4 24 Oct 2014 Peter Neumann Chapter 4.1, 5.1 changing object type of
enumeration, Chapter 9.2 not transforming
sequencingkey
0.5 31 Oct 2014 Peter Neumann
0.6 25 Nov 2014 Peter Neumann
0.7 03 Dec 2014 Peter Neumann
0.8 12 Dec 2014 Peter Neumann
0.81 05 Jan 2015 Peter Neumann
0.82 12 Jan 2015 Peter Neumann Referencing IATA XML Best Practices
0.83 23 Jan 2015 Peter Neumann New testing
0.84 05 Feb 2015 Peter Neumann New testing and adding BBIE short name,
“type” suffix and ASBIE. All highlighted in blue.
0.85 11 Feb 2015 Peter Neumann Adding a test case
0.86 16 Mar 2015 Michael Thomas Added section 3 “Overall Mapping Diagram”
0.89 04 May 2015 Michael Thomas Added section for “PRIM”
For BDT CON & SUP, generate Simple Types
only when the CON/SUP has a restriction
0.93 03 Jun 2015 Michael Thomas Various refinements around associations ;
Consolidated entity mapping tables from each
sub-section x.1 into one overall table in 3.2
0.94 29 Jan 2019 Michael Thomas Corrected naming convention for an
Enumeration.
Corrected transformation of a SUP so as not
to create a simple type if the SUP has an
enumeration.
0.95 29 Jan 2019 Graham Ferguson Removed option to implement a BBIE as an
attribute or an element. Only element is
allowed.

Page 3 of 41
1 INTRODUCTION
1.1 Purpose
The purpose of the document is to describe the customization for the airline industry data model of the following two Enterprise Architect features:
• MDG Transformation from Platform-Independent model to XML Platform-Specific model,
• Code Generation of XML Schema files

The customizations are to be used in the following 4 contexts:

1. model transformation of source (Business Service specific Logical Data Model T3) into the target (XML Platform-specific Message Schema Model T4),
2. code generation from the source (XML Platform-specific Message Schema Model T4) into the target (Message Schema file)
3. model transformation of source (Integrated Logical Data Model I3) into the target (XML Platform-specific Library Schema Model I4),
4. code generation from the source (XML Platform-specific Library Schema Model I4) into the target (Library Schema file).

The end goal is to generate XSD files complying with IATA XML Best Practices, and following the UN/CEFACT XML NDR Technical Specification V3.0. Note that
while UN/CEFACT dictates to a large degree how to model the PIM layer, and what to generate into the ultimate XSD file, we have more freedom about the
“intermediate” XSD model in EA, which the PIM is transformed into as a first step. This document mainly specifies customizations to the PIM-to-XSD
Transformation tool, recognizing that we actually do not customize the built-in XSD-model-to-XSD-file generation tool. When this document also gives examples of
how the ultimate XSD file should look, it gives these examples with the goal of testing the end-to-end chain, not with the goal of customizing the xsd file generator.

1.2 Audience
The audience of the document is the DMTFG (Data Model & Tooling Focus Group) members.

Page 4 of 41
1.3 Approach
The 4 contexts mentioned above correspond to the red circles
in the chart to the right of our Message modeling approach
(please see Message Approach Document for details.)

2 Prerequisites
All elements (PRIM, BDT, ABIE) needed for a package to be transformed must be present in this package.
For XML Library Schema transformation, this will apply to Information Domain Logical Data Model packages.
For XML Message Schema transformation, this will apply to Business Service Logical Data Model packages.

To achieve the pre-requisite, a Common Objects Replication tool copying shared elements such as BDTs from common packages into the package to be
transformed will be developed. It’s specifications are not included in the present document.

Page 5 of 41
3 High level Mappings

3.1 Overall Mapping Diagram

The below diagram provides an overview of Core Component to XML artifact mapping.
For description of each mapping, please refer to the next sections of the present document.

Page 6 of 41
3.2 Class and Attribute Mappings for ENUMs and BIEs f
Note : Parts of the below table correspond to native EA behavior. Customizations are written in blue color.

Source/PIM Model Target/XSD Model Target/XSD Model XSD File Obj. Library Message Reference to
Object Type + «Stereotype» Object Type + «Stereotype» Object Name key Artifact Transform Transform IATA XML Best Practices
Class «ENUM» Enumeration «enumeration» ENUM N*+”Content simpleType Y Y Chapter 8 - Enum. and code lists
Type”
Attribute «CodelistEntry» Attribute «CodelistEntry» ENUM N* enumeration value=… Y Y Chapter 8 - Enum. and code lists
if BDT without SUP:
Class «XSDSimpleType» BDT N* +”Type” simpleType Y Y Chapter 4.5
Class «BDT»
Attribute «CON» n/a (contributes to above) n/a restriction base=… Y Y Chapter 4.7
if BDT with SUP: complexType
Class «XSDComplexType» BDT N* +”Type” Y Y Chapter 4.4
Class «BDT» simpleContent
Attribute «CON» if restriction: Y Y Chapter 4.4
not referencing an ENUM Class «XSDsimpleType» BDT N* +”Value” simpleType
Generalization extension base=…
else: (empty)
(none / ref to XSD built-in type) n/a extension base=…
Attribute «CON» Generalization (empty) extension base=… Y Y Chapter 4.4
referencing an ENUM (ref to simple type representing
the ENUM)
Attribute «SUP» if SUP with restriction: Y Y Chapter 4.4
Class «XSDsimpleType» BDT N* + SUP N* simpleType
in all cases:
Attribute «XSDAttribute» SUP N* attribute name=…
Class «ABIE» Class «XSDComplexType» ABIE N** +”Type” complexType Y Y Chapter 4.4
sequence
Attribute «BBIE» Attribute «XSDElement» BBIE N** +BDT N* Y Y Chapter 4.7, 5.2, 9.1
XSDattribute

XSDelement
Aggregate Assoc. «ASBIE» Directional Assoc. «(empty)» ASBIE Name XSDelement N Y Chapter 7
Source Role Name (N/A - part of above) If source role not empty
then target role =

Page 7 of 41
 ASBIE Source Role N*
+ associated ABIE
N**
Generalization «(any)» (same as source) «(same as (same as source) extension base= N Y Chapter 7
source)» parent ABIE N**

N* = Name in Upper Camel case, and with UR*** N** = Name or (IATA tagged value) Short Name if not blank, in Upper Camel case and with UR***
UR*** = any Underscores Removed as per UN/CEFACT XML NDR (note: in UN/CEFACT, underscore space separates qualifier from object/property terms)

4 PRIM
There is a finite list of 11 PRIMs (Primitive Data Types) defined by UN/CEFACT. We have defined them once for all in the PRIM Library so they can be referenced
from where appropriate.

The PRIMs themselves do not get transformed into any XML artifact (consistently with native EA transformation which does not perform any transformation of data
types either). However the references to the PRIMs need to be transformed.

PRIMs are only referenced from BDT CONs & SUPs (through their “type” property) and ENUMs (through the “restricted primitive” tagged value).

• Within the XSD SimpleType and XSD Enumeration models created from the BDT CONs & SUPs and ENUMs :
the reference to the PRIM needs to be translated into a reference to a standard XSD data type as per the below table.

Reference to PRIM Reference to standard XSD data type

Binary base64binary
Boolean boolean
Decimal decimal
Double double
Float float
Integer integer
Normalized String normalizedString
String string
TimeDuration duration
TimePoint dateTime
Token token

Page 8 of 41
• Within the XSD SimpleType models created from the BDT CONs & SUPs :
The potential restriction in the SimpleType is the one from the CON or SUP. Any facet restriction that would be (uselessly) indicated inside the PRIM is
ignored.

Page 9 of 41
5 Enumeration – without Values
Note : Enumerations to be transformed are supposed to be of object type “Class”. This is a deviation from the UPCC profile from the UN/CEFACT developers site
but coherent with native EA, and implemented in our IATA EA profile. We believe that in the UPCC profile from the UN/CEFACT developers site this was a mistake.

5.1 Detailed Properties Transformation Mapping

Note1 : keep the out-of-the-box feature to delete all spaces in the source name string before creating the target name string.

*Note2 : UN/CEFACT suggests for many of its tagged values to generate corresponding text in annotations which is in XML syntax. Firstly, we will generate this as
an addition to the I4/T4 model Notes field of the relevant element, so out-of-the-box EA codegen will then carry the text forward into the xsd annotation. Secondly,
the XML format causing some challenges for transformation, we have decided to simply generate the syntax “name of tagged value =” value. E.g. instead of
generating <codeListAgencyIdentifier>xyz</codeListAgencyIdentifier>, we generate codeListAgencyIdentifier=”xyz”.

Transformation Rule Source Target Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
Transform EA_ObjectType businessTerm
TaggedValues_UNCEFACT
codeListAgencyIdentifier Add to Property “Notes”: Y Y Chapter 9.8
codeListAgencyIdentifier
=”xyz” ; (see 5.1 *Note2)
codeListAgencyName Add to Property “Notes”: Y Y Chapter 9.9
codeListAgencyName=”
xyz” ; (see 5.1 *Note2)
codeListIdentifier Add to Property “Notes”: Y Y
codeListIdentifier=”xyz”
(see 5.1 *Note2)
codeListName Add to Property “Notes”: Y Y
codeListName=”xyz”
(see 5.1 *Note2)
definition
dictionaryEntryName
enumerationURI Add to Property “Notes”: Y Y Chapter 9.10
enumerationURI =”xyz”
(see 5.1 *Note2)

Page 10 of 41
 languageCode
minorVersionIdentifier
modificationAllowedIndicator
restrictedPrimitive Set: restrictedPrimitive Y Y
revisionIdentifier
status
uniqueIdentifier
usageRule
versionIdentifier

Remark: If the enumeration without values has to have additional restrictions (facets), these will be specified in I3 within the BDT referencing the enumeration. The
transformation of such a BDT is described in the BDT – without supplementary attributes chapter.
NEED TO UPDATE : add Restriction Tagged Values to the above table and how they will be transformed.

5.2 Code generation Mapping

Not applicable

5.3 Sample XML Code

<xs:simpleType name=”GenderType”>
<xs:annotation>
<xsd:documentation>
<codeListAgencyIdentifier>xyz</codeListAgencyIdentifier>
<codeListAgencyName>xyz</codeListAgencyName>
<enumerationURI>xyz</enumerationURI>
<codeListIdentifier>xyz</codeListIdentifier>
<codeListName>xyz</codeListName>
</xsd:documentation>
</xs:annotation>
<xs:restriction base=”xs:string”>
</xs:restriction>
</xs:simpleType>

Page 11 of 41
6 Enumeration – with Values
Note : Same as for / see Enumerations - without Values.

6.1 Detailed Properties Transformation Mapping

Note: keep the out-of-the-box feature to delete all spaces in the source name string before creating the target name string.

Transformation Rule Source Target Obj. Library Message Reference to IATA XML
Transform Transform Best Practices
Transform EA_ObjectType businessTerm
TaggedValues_UNCEFACT
codeListAgencyIdentifier (same as in 5.1) Y Y Chapter 9.8
codeListAgencyName (same as in 5.1) Y Y Chapter 9.9
codeListIdentifier (same as in 5.1) Y Y
codeListName (same as in 5.1) Y Y
definition
dictionaryEntryName
enumerationURI (same as in 5.1) Y Y Chapter 9.10
languageCode
minorVersionIdentifier
modificationAllowedIndicator
restrictedPrimitive Set: restrictedPrimitive Y Y
revisionIdentifier
status
uniqueIdentifier
usageRule
versionIdentifier
Transform EA_ AttributeType codeName
TaggedValues_UNCEFACT
status
businessTerm
definition
dictionaryEntryName

Page 12 of 41
 enumeration
fractionDigits
languageCode
length
maxExclusive
maxInclusive
maxLength
minExclusive
minInclusive
minLength
minorVersionIdentifier
pattern
revisionIdentifier
totalDigits
uniqueIdentifier
usageRule
versionIdentifier
whiteSpace

Note: It would make no sense to define restrictions such as maxLength etc. at the level of each attribute which would be the case for the above. If a restriction is to
be defined, this is done in the BDT CON or SUP referencing the Enumeration, and will then be transformed as appropriate.
NEED TO UPDATE : add Restriction Tagged Values to Object Type section of the table and how they will be transformed.

6.2 Code generation Mapping

Not applicable

6.3 Sample XML Code

<xs:simpleType name=”GenderType”>

<xs:annotation>
<xsd:documentation>
<codeListAgencyIdentifier>xyz</codeListAgencyIdentifier>

Page 13 of 41
 <codeListAgencyName>xyz</codeListAgencyName>
<enumerationURI>xyz</enumerationURI>
<codeListIdentifier>xyz</codeListIdentifier>
<codeListName>xyz</codeListName>
</xsd:documentation>
</xs:annotation>

<xs:restriction base=”xs:string”>
<xs:enumeration value=”Female”/>
<xs:enumeration value=”Indeterminate”/>
<xs:enumeration value=”Male”>
<xs:annotation>
<xs:documentation>means male</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value=”Unknown”/>
</xs:restriction>
</xs:simpleType>

Page 14 of 41
7 Business Data Types (BDT) without Supplementary Attributes

7.1 Detailed Properties Transformation Mapping

Note: keep the out-of-the-box feature to delete all spaces in the source name string before creating the target name string.

Key properties of the XSD Simple Type (which is a class) are set as follows :
• the restriction/list radio-button is set to “restriction”
• the “type” property of the simpleType is set to :
o the Name of the PRIM converted to its corresponding standard XSD data type (see section PRIM) when the CON refers to a PRIM
o the Name of the Enumeration when the CON refers to an enumeration.

Transformation Rule Source Target Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
n/a derivation:Restriction Y Y
Transform EA_ObjectType Add the suffix “Type” Y Y
Property_Name
Transform EA_ObjectType businessTerm
TaggedValues_UNCEFACT
definition
dictionaryEntryName
languageCode
uniqueIdentifier
usageRule
versionIdentifier
Transform EA_ObjectType businessTerm
AttributeType
TaggedValues_UNCEFACT
definition
dictionaryEntryName
enumeration
languageCode
fractionDigits fractionDigits Y Y Chapter 7.5
length length Y Y Chapter 7.5
maxExclusive maxExclusive Y Y Chapter 7.5

Page 15 of 41
 maxInclusive maxInclusive Y Y Chapter 7.5
maxLength maxLength Y Y Chapter 7.5
minExclusive minExclusive Y Y Chapter 7.5
minInclusive minInclusive Y Y Chapter 7.5
minLength minLength Y Y Chapter 7.5
modificationAllowedIndicator
pattern pattern Y Y Chapter 7.5
totalDigits totalDigits Y Y Chapter 7.5
uniqueIdentifier
usageRule
versionIdentifier
Transform EA_ObjectType Type of CON Attribute (PRIM) Type of Simple Type Y Y
AttributeType_Properties (xsd built in type)

Regarding UN/CEFACT TaggedValues for facet restrictions (fractionDigits, length, maxExclusive, maxInclusive, maxLength, minExclusive,minInclusive, minLength,
pattern, totalDigits) :
• Each corresponding tagged value in the Target XSDsimpleType model should be created if and only if the source tagged value is non-empty,
• Each corresponding tagged value in the Target XSDsimpleType model will be set to the value in the source tagged value (when the latter is non-empty).

Note 1 : if we did systematically create all these tagged values in the XSDsimpleType model and then leave them empty where there is no restriction, the (out-of-
there-box) code generation tool would generate restriction lines in the XSD for each tagged value with value =””, which we want to avoid.

Note 2 : If there is no restriction, we will still generate “xs:restriction base= …” but without any restriction following this statement.

Note3 : if the CON references an ENUM, any facet restrictions must be modeled in the ENUM. In EA they will show in the CON as inherited tagged values, however
they must not be overridden in the CON. In case a modeler by mistake puts restrictions into a CON that also references an ENUM, the transformation tool can
unfortunately not detect this scenario, and will process the restrictions and later crash. !!!

7.2 Code generation Mapping

Not applicable

7.3 Sample XML Code

This example shows the mapping for Business Data Types without Supplementary Attributes and without Enumeration Content :
<xs:simpleType name=”PercentType”>

Page 16 of 41
 <xs:annotation>
<xs:documentation>A percent is a value representing a fraction of one hundred, expressed as a quotient.</xs:documentation>
</xs:annotation>
<xs:restriction base=”xs:decimal”>
<xs:maxInclusive value=”100.00”/>
<xs:minInclusive value=”0.01”/>
</xs:restriction>
</xs:simpleType>

This example shows the mapping for Business Data Types without Supplementary Attributes and with Enumeration Content.
<xs:simpleType name=”GenderType”>
<xs:restriction base=”Gender”/>
</xs:simpleType>

Page 17 of 41
8 Business Data Types (BDT) with Supplementary Attributes
Note: keep the out-of-the-box feature to delete all spaces in the source name string before creating the target name string.

If a BDT has CON and/or SUP attributes with facet restriction (and only when it has a restriction) the model transformation will generate :
1. An XSD Simple Type for each CON and/or SUP attribute (and only those CON and/or SUP attributes) holding a facet restriction.
2. An XSD Complex Type (for the BDT itself) with
• a Generalization association to the underlying simple of built-in type for the CON, which in the XSD file will be generated into <xs:extension base= ...
• an attribute for each SUP.

The name of the XSD Simple Type created from “CON” will be “Name of the BDT” + ”Value”.
The name of the XSD Simple Type created from “SUP” will be “Name of the BDT” + ”Name of the source SUP attribute”.
All created Simple Types must be referenced from the XSD Complex Type attributes using “type” property.

8.1 Detailed Properties Transformation Mapping

Transformation Rule Source Target Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
Transform EA_ObjectType = Add the suffix “Type” Y Y Chapter 4.4
Property_Name
Transform EA_ObjectType = businessTerm
TaggedValues_UNCEFACT
definition
dictionaryEntryName
languageCode
uniqueIdentifier
usageRule
versionIdentifier
Transform EA_ObjectType = businessTerm (Refer to section 7.1)
AttributeType
TaggedValues_UNCEFACT
definition (Refer to section 7.1)
dictionaryEntryName (Refer to section 7.1)
enumeration (Refer to section 7.1)

Page 18 of 41
 languageCode (Refer to section 7.1)
fractionDigits (Refer to section 7.1)
length (Refer to section 7.1)
maxExclusive (Refer to section 7.1)
maxInclusive (Refer to section 7.1)
maxLength (Refer to section 7.1)
minExclusive (Refer to section 7.1)
minInclusive (Refer to section 7.1)
minLength (Refer to section 7.1)
modificationAllowedIndicator (Refer to section 7.1)
pattern (Refer to section 7.1)
totalDigits (Refer to section 7.1)
uniqueIdentifier (Refer to section 7.1)
usageRule (Refer to section 7.1)
versionIdentifier (Refer to section 7.1)

Note3 : if the SUP references an ENUM, any facet restrictions must be modeled in the ENUM. In EA they will show in the SUP as inherited tagged values, however
they must not be overridden in the SUP. In case a modeler by mistake puts restrictions into a SUP that also references an ENUM, the transformation tool can
unfortunately not detect this scenario, and will process the restrictions and later crash. !!!

8.2 Code generation Mapping

Not applicable

8.3 Sample XML Code

<xs:element name="SeatNumber" maxOccurs="99">
<xs:annotation>
<xs:documentation>The seat number.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="AlphaNumericStringLength1to4">
<xs:attribute name="PsgrReference" type="StringLength1to16"/>

Page 19 of 41
 <xs:attribute name="Number" type="AlphaNumericStringLength1to4"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

Page 20 of 41
9 ABIE
9.1 Detailed Properties Transformation Mapping
Note: keep the out-of-the-box feature to delete all spaces in the source name string before creating the target name string.

Transformation Rule Source Target Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
Transform businessTerm
EA_ObjectType_TaggedValues_
UNCEFACT
definition
dictionaryEntryName
languageCode
uniqueIdentifier
usageRule
versionIdentifier
Transform ShortName If ShortName is not Y Y
EA_ObjectType_TaggedValues_I empty Then Name of
ATA Comp.Type=ShortName
Set “Modelgroup” to Y Y
“sequence”

9.2 Code generation Mapping

Not applicable

9.3 Sample XML Code

<xs:complexType name=”Person”>
<xs:annotation>
<xs:documentation>A Person is a human being.</xs:documentation>
</xs:annotation>

Page 21 of 41
 <xs:sequence>
<xs:element name=”DateOfBirth” type=”Date” minOccurs=”1” maxOccurs=”1”/>
<xs:element name=”Gender” type=”Gender” minOccurs=”1” maxOccurs=”1”/>
<xs:element name=”GivenName” type=”Name” minOccurs=”1” maxOccurs=”1”/>
<xs:element name=”MiddleName” type=”Name” minOccurs=”0” maxOccurs=”3”/>
<xs:element name=”NameTitle” type=”ShortName” minOccurs=”1” maxOccurs=”1”/>
<xs:element name=”SurName” type=”Name” minOccurs=”1” maxOccurs=”1”/>
<xs:element name=”SurNamePrefix” type=”ShortName” minOccurs=”1” maxOccurs=”1”/>
</xs:sequence>
</xs:complexType>

Page 22 of 41
10 BBIE
Regarding the name of the XSD Element or XSD Attribute to be created – stated to be “ BBIE N** +BDT N* “ in the overview table in section “Class and Attribute
Mappings for ENUMs and BIEs” – the following additional logic is needed :
• Because in a number of cases, the name of the BDT may already be present at the end the BBIE name (e.g. a “Booking Confirmed Indicator” might already
have the BDT name “Indicator” at the end), the logic should be to append the BDT name only if it is not yet present at the end of the BBIE name.

10.1 Detailed Properties Transformation Mapping

Transformation Rule Source Target Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
Transform EA_ObjectTypeAttribute businessTerm
TaggedValues_UNCEFACT
definition
dictionaryEntryName
languageCode
sequencingKey ***
uniqueIdentifier
usageRule
versionIdentifier
Transform EA_ObjectTypeAttribute Src Reso/RP Nb Add to Property “Notes”: Y Y
TaggedValues_IATA Src Reso/RP Nb=”xyz”
(see 5.1 *Note2)
Src Data Element Name Add to Property “Notes”: Y Y
Src Data Element Name =
”xyz” ; (see 5.1 *Note2)
Src Manual and Edition Add to Property “Notes”: Y Y
Src Manual and Edition =
”xyz” ; (see 5.1 *Note2)
Src Location in Manual Add to Property “Notes”: Y Y
Src Location in Manual =
”xyz” ; (see 5.1 *Note2)

Page 23 of 41
 IATA transform to XSD Attribute If taggedValue =”Y” then Y Y
transform the BBIE into an
“XSDAttribute”
Else transform the BBIE
into an “XSDElement”
ShortName If ShortName is not empty Y Y
then Name of xsdElement/
xsdAttribute=ShortName
Property isID : is flagged to flag an see chapter Identifier (ID) Chapter 4.11
identifier attribute Complex Type Generation
minOccurs : Optionality is defined “minOccurs” for a BBIE Y Y Chapter 9.3
in the Mini-mum Occurrence translates to an XSD
(MinOccurs= ”0”) indicator of the Attribute:
element and the Use If source minOccurs=0
(use=”optional”) indicator of the then set target tagged
attribute. value “use=optional”
Position within ABIE Position of the BBIE within the Set “Position” tagged Y Y
ABIE, as displayed in the Project value = 100, 200, 300, etc.
Browser, or when opening the for BBIEs in position 1, 2,
ABIE (which is the same). * 3 etc.**

* This order can theoretically be different from the display on diagrams, where class attributes appear grouped by stereotype, however in our case the stereotype will always be “BBIE”.
** Filling in the “Position” tagged value with values 100, 200, 300 etc. will allow modelers to “insert” associations between the elements, modifying the XSD model (see section ASBIE).
*** the most straightforward solution for specifying the order of elements in the XSD file – generated either from BBIEs or from associations – would be to ask modelers to fill in the UPCC
Sequencing Key tagged value at logical layer, then have transformation copy the sequencing Key over into the XSD model Position tagged value. Rather than imposing the “pain” and
“confusion” to fill in all the Sequencing Keys one by one while seeing a different order in the EA windows, we prefer to automatically transpose the “graphical” order into the Position tagged
value during transformation, then order the associations at XSD model level.

10.2 Code generation Mapping

10.3 Sample XML Code

<xs:complexType name=”Departure”>
<xs:annotation>

Page 24 of 41
 <xs:documentation>The leaving of an airport by an aircraft.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name=”DepartureAirportCode” type=”Airport” minOccurs=”1” maxOccurs=”1”/>
</xs:sequence>
<xs:attribute name=”DepatureDateTime” use=”optional” type=”DateTime”/>
</xs:complexType>

Page 25 of 41
11 Identifier (ID) Complex Type Generation
In the I3 layer, a BBIE can be flagged as identifying attribute (id). As part of model transformation, an additional Complex Type with the name=”Name(ShortName)
of ABIE+_”ID” and containing all attributes with is_ID flag as XSD attributes has to be created.

business Transformed Model1

business Transformed Model1

I3 «ABIE»
Ticket::Ticket
I3 «ABIE»
«BBIE» Ticket::Ticket
- TotalNumberOfCoupons: Quantity
- «BBIE»
NumberOfBooklets: Quantity {id}
- TotalNumberOfCoupons: Quantity
TicketNumber: Numeric {id}
- NumberOfBooklets:
IssueDate: Date {id} Quantity {id}
- TicketNumber: Numeric {id}
- IssueDate: Date {id}

I4 «XSDcomplexType»
TKT «XSDcomplexType»
I4 «XSDcomplexType» TKT_ID
«XSDAttribute»TKT «XSDcomplexType»
- TKT_Identifier: TKT_ID «XSDAttribute»
TKT_ID
«XSDAttribute» - NumberOfBooklets: Quantity
«XSDElement»
- TKT_Identifier: TKT_ID - «XSDAttribute»
TKTNbr: Numeric
- TotalNumberOfCoupons: Quantity
«XSDElement» - NumberOfBooklets:
IssueDate: Date Quantity
- NumberOfBooklets: Quantity
- TKTNbr: Numeric
- TotalNumberOfCoupons:
TKTNbr: Numeric Quantity
- IssueDate: Date
- NumberOfBooklets:
IssueDate: Date Quantity
- TKTNbr: Numeric
- IssueDate: Date

Page 26 of 41
12 ASBIE
Before documenting mappings, it is important to note four important decisions we have made.

Decision 1 – XSD elements are local

UN/CEFACT XML NDR Technical Specifications stipulate :

An ASBIE represents an association between the associating (parent) ABIE and the associated (child) ABIE. An ASBIE is represented as either a local or global
element, depending upon the type of association
• If the ASBIE is a composite association (AggregationKind=composite), the associated ASBIE is declared as a local element (xsd:element) within the
type (xsd:complexType) representing the associating ABIE. This local element (xsd:element) is of the type (xsd:complexType) of the associated ABIE.
• If the ASBIE is a shared association (AggregationKind=shared), the ASBIE is referenced as a global element (xsd:element) within the type representing
the associating ABIE. The global element (xsd:element) is declared in the same namespace as the associating ABIE and is of the type
(xsd:complexType) of the associated ABIE.

Referencing a global element – as in the second bullet above – would involve using an XSD “ref” attribute. This would be contrary to IATA XML Best Practices
which forbid the usage of ref, conforming with Venetian Blinds. We therefore choose to create local elements (referencing the global complex type of the associated
ABIE) for all kinds of ASBIEs.

Decision 2 – Translation into elements happens at Code Generation stage (only)

Native EA transformation carries PIM associations over into the XSD model as they are, preserving all characteristics including stereotypes. It will then be the Code
Generator’s role to replace associations by XSD elements with the type of the referenced ABIE.

We first envisaged modifying this mechanism, and replace associations by elements already in the XSD model, with the idea that the XSD model would then be an
appropriate place to graphically fix the sequence of all elements (those transformed from BBIEs and those transformed from ASBIEs) within a complex type,
establishing the sequence desired in the subsequently generated XSD file. We rejected this approach because it is actually not the sequence of elements
appearing inside the classes or in the Project Browser that dictate the sequence in the XSD file generated, but the “Position” tagged value. Furthermore, the
replacement at transformation stage would have added very significant complexity to our customizations (when the features comes out of the box at code
generation time)..

We therefore opted to keep the associations in the XSD models.

We are however customizing EA Transformation to fill in the “Position” tagged value with values 1, 2, 3 etc. in the order of LDM elements’ appearance in the Project
Browser (see section BBIE). For Associations, the Transformation tool will create the “Position” tagged value but leave it empty, allowing the modelers to fill in these
tags, in order to put the associations in the right sequence amongst themselves and versus the elements (see also Detailed Mapping here below).

Page 27 of 41
Decision 3 – ASBIEs are transformed into directional associations
Native EA would transform ASBIEs – which are aggregation or composition associations – into exactly that same type of associations in the XML model.

We decided to transform ASBIEs into directional associations, because aggregation/composition are not a valid artifact in the EA XML model. Note that despite of
not being valid as per the EA profile for XSD, they would still have been generate-able into the schema file, however it would not have been possible to
automatically create the Position tagged value inside an aggregation/composition.

Contrary to UN/CEFACT where the ASBIE source->target direction correspond to child->parent, the XSD level directional associations will “naturally” go in the
parent->child direction.

Layer Associating ABIE / Parent --> Associated ABIE / Child

Target <-- Source
Logical Layer – Logical data model
(PIM, UN/CEFACT notations)

Source --> Target

Physical Layer – XSD Model
(standard EA XML profile notations)

Consequently, transformation needs to swap source and target within the association.

Decision 4 – Constructing the xsd Element Name

UN/CEFACT stipulates : [R A08A] Each ASBIE element name MUST be the ASBIE property term and qualifier term(s), and the object class term and qualifier
term(s) of the associated ABIE.

As per UN/CEFACT, the ASBIE property name should be the role of the associated ABIE in the association. The name of the element ultimately generated ought
to be the concatenation ASBIE Source Role N* + associated ABIE N**. For EA code gen to correctly generate this into the XSD file, the concatenated string ought

Page 28 of 41
to be in the XSD Association source role. Hence Transformation will have to compose that string, and put it into the xsd Model Association Source Role. The name
of the XSD association will not matter for code gen.

Note that :
• The role of the associated ABIE goes more naturally into the EA source role name of the ASBIE than into the ASBIE name. This is also what is done in the
Waste Movement sample XSD provided by UN/CEFACT.
• The ASBIE Source Role may be empty in many cases. It mainly needs to be filled in when multiple ASBIEs go from the same associating ABIE to the same
associated ASBIE. Whether the Source Role is empty or not, note that we will not append “Type” at the end of the name (from the associated ABIE)
generated for the xsd element.

12.1 Detailed Properties Transformation Mapping

Transformation Rule Obj. Library Message Reference to

Transform Transform IATA XML Best Practices
Leave XML model association stereotype “empty” N Y
If ABIE source role is not empty then : N Y
set XML model association target role to ASBIE Source Role N* + associated ABIE N**
Else leave XML model association target role “empty”
Create the tagged value “Position” in section "Connector Target" of the Association or N Y
Generalization. Leave it empty for the modeler to decide on the sequence of elements generated
from the ASBIE, within the associating ASBIE’s complex type.

12.2 Code generation Mapping

The below are as per standard behavior of the EA XSD code generator, except for adding the ASBIE name as a prefix in the name of the XSD element created.

Transformation Rule Lib.XSD Msg XSD Reference to

Code Gen Code Gen IATA XML Best Practices
For each ASBIE whose target is an (associating) ABIE, create an XSD element within the target N Y
ABIE’s complex type with the concatenated name “ASBIEsourceRole+sourceABIEname”. From the
XSD element, reference via type property the source (associated) ABIE’s complex type.
Transform Source Role Cardinality of the ASBIE into Multiplicity lower bound and upper bound of N Y
the new XSD element

Page 29 of 41
12.3 Sample XML Code

The XML code is the same no matter whether the aggregation type is aggregate or shared.

Page 30 of 41
13 Schema Version Generation
The following aims at automatically generating the same characteristics of XSDs as created manually today, in the case of message schemas.
Object Library Schemas is a new concept. Individual versioning other than indicating the PADIS release will not be relevant for those.

Obj. Library Message

Schemas Schemas
Generate an “id” attribute – the same in each XSD generated – with the current PADIS release. A new PADIS release will most probably Y Y
translate into setting up a new MS SQL instance. The PADIS release of that instance could be either hardcoded in the generation
script/template or parameterized in a central place in that instance.
Generate a “version” attribute for the specific XML schema, copying the EA “Version” attribute of the package representing the schema N Y
(inT3). Note that schema versions are maintained at T4 level (not at T3), and that EA versions of any underlying elements (XSD elements,
attributes, complex types, simple types) are ignored i.e. not used.

Sample line of XSD generated:

<xs:schema xmlns=”http://www.iata.org/IATA/2007/00” xmlns:xs=”http://www.w3.org/2001/XMLSchema”

targetNamespace=”http://www.iata.org/IATA/2007/00” elementFormDefault=”qualified” version=”2.001” id=”IATA2015.1”>

Page 31 of 41
14 Test Cases for Model Transformation (I3 to I4 and T3 to T4)
Note : all test conditions will be run from T3 to T4 except where I3 is explicitly stated.

Nb Artifact / Test Case Test object Status Expected Results

Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
1 ENUM – Delete space in name Enum without p The name of the transformed enumeration should be
without values Values “EnumwithoutValues”
2 ENUM – Transfer the tagged values content Enum without p The content of the tagged values should appear in the description field:
without values into description- Values
<codeListAgencyIdentifier>xxx</codeListAgencyIdentifier>
<codeListAgencyName>yyy</codeListAgencyName>
<codeListIdentifier>zzz</codeListIdentifier>
<codeListName>aaa</codeListName>
<enumerationURI>bbb</enumerationURI>
3 ENUM – Set restricted primitive Enum without p The tagged value “Restricted Primitive” is set in the transformed
without values Values enumeration.

<xs:simpleType name=”EnumwithoutValues”>
<xs:annotation>

</xs:annotation>
<xs:restriction base=”xs:Iinteger”>

</xs:restriction>
</xs:simpleType>
4 ENUM – with Delete space in name Gender p The name of the transformed enumeration should be “GenderGender”
values Gender
5 ENUM – with Transfer the tagged values content Gender p The content of the tagged values should appear in the description field:
values into description Gender
<codeListAgencyIdentifier>xxx</codeListAgencyIdentifier>
<codeListAgencyName>yyy</codeListAgencyName>
<codeListIdentifier>zzz</codeListIdentifier>
<codeListName>aaa</codeListName>
<enumerationURI>bbb</enumerationURI>

Page 32 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
6 ENUM – with Set restricted primitive Gender p The tagged value “Restricted Primitive” is set in the transformed
values Gender enumeration and in the XSD code.

<xs:simpleType name=”GenderGender”>
<xs:annotation>

</xs:annotation>
<xs:restriction base=”xs:Sstring”>

</xs:restriction>
</xs:simpleType>

7 ENUM – with Many values (100) Enumeration1 p Just transform the enumeration from I3 to I4.
values 00
8 ENUM – with One of the values has a wrong EnumStereo f Same stereotype in XSD model as in source.
values stereotype and one has no (note : even invalid stereotypes are carried through).
stereotype, while other values have
the correct stereotype Actual result : empty stereotype translates to “attribute”.
9 ENUM – with With Special Primitive : Binary, Float, EnumStereo p The tagged value “Restricted Primitive” is set in the transformed
values Token, Integer, Timepoint enumeration and in the XSD code.

10 ENUM – with Invalid value : non-numeric string EnumStereo p Will cause an invalid XSD code after code generation from I4.
values entered for Enum of Primitive type (will test this kind of issue in future model quality validation tool)
“Integer”
11 BDT – without Create an XSD Simple Type for a GenderGende f An XSD Simple Type “GenderType” referring to another XSD Simple
SUP and with BDT with only a CON attribute with r, GenderType Type “GenderGender” (which is not generate here, but generated from
enumeration enumeration content the ENUM Gender Gender)
content
<xs:simpleType name=”GenderGender”>
<xs:annotation>
<xs:documentation>gender
description</xs:documentation>
</xs:annotation>
<xs:restriction base=”xs:string”>
<xs:enumeration value=”Female”>

Page 33 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
<xs:annotation>
<xs:documentation>female
description</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value=”Indeterminate”/>
<xs:enumeration value=”Male”/>
<xs:enumeration value=”Unknown”/>
</xs:restriction>
</xs:simpleType>

<xs:simpleType name=”GenderType”>
<xs:restriction base=”GenderGender”>
</xs:restriction>
</xs:simpleType>
</xs:schema>

Actual Result : GenderTypeType has “base = string.

12 BDT – without Create an XSD Simple Type for a Numeric f An XSD SimpleType “Numeric”
SUP BDT with only a CON attribute
without restrictions Actual result : SimpleType has empty restriction lines
13 BDT – without Set: Restriction Numeric p Tagged Value “derivation” in transformed XSD Simple Type is set to
SUP “restriction”
14 BDT – without Delete space in name Gender Type p Name of the XSD Simple Type created = “GenderTypeType”
SUP
15 BDT – without Set type of simple type based on f in <xs:simpleType name="AirlineDesignatorType"> : base="xs:string"
SUP referenced PRIM (xsd built in type) in <xs:simpleType name="IndicatorType"> : base="xs:boolean"
- for String: …………… AirlineDes in <xs:simpleType name="DateType"> : base="xs:string"
- for Boolean: ………..  Indicator in <xs:simpleType name="PercentType"> : base="xs:decimal">
- for TimePoint: ……...  Date
- for Decimal: …………  Percent Actual result : all correct except xs:String with capital S
16 BDT – without Create a XSD Simple Type for a BDT Airline p In XSD file :
SUP with only a CON attribute with Designator <xs:simpleType name="AirlineDesignatorType">
restrictions <xs:annotation> /// not shown here ///
</xs:annotation>

Page 34 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
<xs:restriction base="xs:String">
etc …
17 BDT – without Transfer the type of a CON Attribute AirlineDesigna a <xs:simpleType name="AirlineDesignatorType">
SUP into the SimpleType as xsd built-in tor <xs:annotation>
type. …
</xs:annotation>
<xs:restriction base="xs:string">
Actual result : almost correct but upper case “S” in string
18 BDT – without Delete space in name Airline p Name of the XSD Simple Type created = “AirlineDesignatorType”
SUP Designator
19 BDT – without BDT with only a CON (not referencing Airline p simple type’s annotations has the notes from the BDT and only those
SUP an enumeration), and different notes Designator from the BDT :
in BDT and in CON. “The 2-character code assigned to a carrier by IATA and published in the
IATA Airline Coding Directory or the 3-alphabetic codes assigned to a
carrier by ICAO, along with the identity (name) of that airline if that
designator is a duplicate IATA designator.”
20 BDT – without Set: Restriction Airline p XSD model : “Restriction” is checked within XSDsimpleType properties
SUP Designator XSD file : <xs:restriction base="xs:String"> generated within simpleType
21 BDT – without Transfer tagged value restrictions Airline f <xs:minLength value=”2”>
SUP content to XSD Simple Type facet Designator <xs:maxLength value="3"/>
restriction <xs:pattern = ([A-Z]{3}|[A-Z]{2})|([0-9][A-Z])|([A-Z][0-9])
Actual result :maxLength comes through but not minLength and pattern
22 BDT – without BDT missing / BIE references BDT in Customer, p The reference to another package will be removed an put into the correct
SUP other package. Despite of our future CustomerIden package.
pre-processor let’s imagine that this tifier refers to
happens. Tools should not crash and BDT: Identifier
rather give a reasonable error in a different
message Package
23 BDT – Create an XSD Complex Type for a BDT Country f Country Sub-Div. CON
with SUP BDT and : Sub-Division, -> generate simple type CountrySub-DivisionValue
BDT Code -> reference is as follows :
• an XSD Simple Type for each <xs:element name="Value" type="CountrySub-DivisionValue"
of BDT attributes that have a
restriction and reference the Country Sub-Div. SUP

Page 35 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
XSD Simple Types from the -> generate s.t. CountrySub-DivisionCountrySub-DivisionType
Complex Type XSD element / -> reference it as follows :
attributes <xs:attribute name="CountrySub-DivisionType"
type="CountrySub-DivisionCountrySub-DivisionType "
• Reference the xsd built-in type
directly from the Complex Type Code CON -> reference built-in type “string” :
XSD element / attributes when <xs:element name="Value" type="xs:string" ...
there are no restrictions.
Code List Identifier -> reference built-in type “string” :
<xs:attribute name="ListIdentifier" type="xs:string"

Actual Result :
complex type does not correctly reference the simple types
Built-in types should say : “type="xs:string” instead of :
type="String".
24 BDT – The CON and SUP have restrictions Code f <xs:simpleType name="CountrySub-DivisionValue">
with SUP so XSDsimpleTypes will be created BDT Country <xs:restriction base=…
for them : Sub-Division
<xs:simpleType name="CountrySub-DivisionSub-DivisionType">
• name of Simple Type <xs:restriction base=…
created from CON is :
“BDT Name” + ”Value”. Actual result : simple types generated with correct names, however :
• name of Simple Type • complex type of BDT does not correctly reference the simple
created from SUP is : types generated,
“BDT Name” +”SUP Name” • restrictions from the CON & SUP are missing in the simple types
25 The 23 stan- Check all, BBIEs should reference at CheckAllBDTs p All BDTs are referenced at least one from a BBIE.
dard BDTs least once
26 ABIE If Tagged Value ShortName is non- Ticket p <xs:complexType name="TKTType">
empty then Name of ComplexType =
ShortName
27 ABIE Set “Modelgroup” to “sequence” Ticket p
28 ABIE ABIE with many BBIEs (100) p

Page 36 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
29 BBIE Profile change “TaggedValue “IATA Ticket p 2 tagged values, one needs to be removed in the profile
transform to XSD” needs to be done
before

Transform all
EA_ObjectTypeAttribute with
TaggedValue “IATA transform to XSD
Attribute”=”” into “XSDElement”

Transform all
EA_ObjectTypeAttribute with
TaggedValue “IATA transform to XSD
Attribute”=”Y” into “XSDAttribute”
30 BBIE If Tagged Value ShortName is not TicketNumber p <xs:element name="TKTNbr" type= …
empty Then Name of
BBIE=ShortName
31 BBIE Transform TicketNumber p
EA_ObjectTypeAttributeType_Tagge
dValues_IATA into property notes
32 BBIE Create an additional Complex Type Original ABIE: p <xs:complexType name="TKTID">
with the name=”Name(ShortName) of Ticket <xs:sequence>
ABIE+”ID” <xs:element name="IssueDate" type="Date"
And copy all attribute with is_ID flag minOccurs="1" maxOccurs="1"/>
as XSD attributes to the new <xs:element name="TotalNumberOfCoupons"
ComplexType. type="Quantity" minOccurs="1" maxOccurs="1"/>
Create an additional XSDAttribute <xs:element name="TicketNumber" type="Numeric"
into the ComplexType of the original minOccurs="1" maxOccurs="1"/>
ABIE as reference to the ID Complex </xs:sequence>
Type. </xs:complexType>
33 ASBIE Create for each ASBIE which points ABIE: a Element is created, name of element is wrong
to an ABIE an XSDElement with the Departure
name concatenated ASBIE: is
“ABIEname+associated ABIEname” used for
and reference the new XSDElement Associated
to the “Associated ABIE” ABIE: Airport

Page 37 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
34 ASBIE With cardinality being 1 to many (e.g. f 32+34 : Action : JD+MT to explore ‘position tagged value” and decide /
1..10), make sure the occurrence is confirm for good if the new approach should be to have associations in
transformed into the target element T4 and let the Code Generator transform them into XSD elements.
property of ComplexType
35 Inheritance While not UN/CEFACT compliant we f e.g. TransportMovement ABIE with sub-types eg DatedFlight ABIE with
Association may need this between abstract association “specialization” without UNCEFACT native EA Association
between ABIEs component ABIEs and their sub-type and then check model transformation from EA, with real attribute
ABIEs. Standard EA behavior should inheritance
still work, generating within the sub-
type’s ABIE complexType (of Creates an “association” connection between ComplexType
complex content) an xsdExtension “TransportMovement” and “DatedFlight” no BBIE inheritance
Base = … referencing the abstract
component ABIE’s complexType (in Jim to update the test object and expected result
the case where the the sub-type ABIE
only has one parent that it has a
Generalization to).

To be verified in the xsd file.

36 Order of XSD elements within a complex type With any ABIE
The new order of BBIEs from the ABIE is reflected in the xsd file.
elements must appear in the exact same order
as the BBIEs within the source ABIE.
Change the position of one BBIE
using Control Arrow Up or Down
within the Class Attributes window,
re-transform, re-generate the xsd.
Note : this is achieved through the
Position tagged value, however
verification should be done in the xsd
ultimately generated.
37 Order of Transform an ABIE. Increase the With any ABIE xsdElements representing the 2 ASBIEs are positioned just before the
Associations value of the Position tagged value of that has at last BBIE, and in the increasing order of their Position tagged value.
the last BBIE by 2. Fill in the Position least 2 BBIEs
tagged values on the ASBIEs towards and 2 ASBIEs.
2 associated ABIEs with the Position

Page 38 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
values just before the BBIE
incremented by 2. Generate the xsd.
38 An entire Info Generate correct I3/T3 model p Into object library XSD, assumption pre-processor replicates all needed
Domain common objects into this Info Domain
39 An entire Info Generate in a decent timeframe (less Action : Michael to do a local test first.
Domain than 1 min) (700 BBIEs and 200 BDT
in 10min) ?????????
40 An entire Info a. With source domain package For each of a, b, c, d, the script should stop with
Domain locked by another user • a message saying you need to unlock source and target
b. With target domain package • without having “altered” or moved any items
locked by another user
c. With one ABIE in source locked Action : Jim to test
by another user
d. With one ComplexType in target
locked by another user
41 All Info f Action : Jim to create special script
Domains in one
shot (from I3
Gov package)
42 Package Test the transformation of Information “to be created All ABIEs transformed.
Locations Domain in I3. ad-hoc” All associations are ignored.
43 Package A message definition deep in the Use test XSD model under T4 gets generated at the same place within the T4
Locations hierarchy in T3 harness 91 hierarchy as is the source in the T3 hierarchy
under I3 (logic
is same for I
and T)
44 Traceability After transform, the following should p The tracebility link “transformed from” is shown in the traceability window.
appear as a “transformed” relation-
ships in the EA Traceability Window :
• ABIE –> ComplexType
• BDT without Sup –> SimpleType
• BDT with Sup –> ComplexType
• Enum –> Enumeration

Page 39 of 41
Nb Artifact / Test Case Test object Status Expected Results
Category (p, f, a)
p=Passed _____________________
f=Failed a=Failed but acceptable |
45 Synchronization Transform, make below changes, re- Action : correct the last 2 bullets once we have agreed how to transform
of source and transform, verify that Transformation ABIEs
target changes : will have updated the target to reflect
change in source :
push source
• Delete an ABIE p
changes into
already created • Add a BBIE to an ABIE
p
XML model • Remove a BBIE from an ABIE p
• Change a BBIE to point to a p
different BDT
• Change a cardinality in an ASBIE f
• Delete an ASBIE f
46 Synchronization • Within an XSDComplexType, Manual change is preserved in the XSD model.
of source and override the element representing
target changes : an associated ABIE by the name
of element of the complex type
retain manual
generated with the identifier
changes in XML
attributes only, and reference the
model upon re-
type of that latter complex type,
transformation
then re-transform.
from source
47 Technical Run a large transformation that takes f
disconnection some time (say all Info Domains), Action: do this test on the cloud at the appropriate point in time.
and re-run : disconnect in the middle (turn off the
wifi / pull out the network cable of Results when running it locally :
your workstation), get online again, After interrupting to wifi connection the cloud service stops and the gives
check that the transformation has an error message. The transformation stops as well.
either completed despite of being So the transformed model and all artefacts need to be deleted and the
disconnected, or if it failed that we transformation repeated again.
can run it again and everything will be
clean at the end of the new run.

Page 40 of 41
15 Annex
15.1 UN/CEFACT Experts contacted
The table below lists the UNCEFACT experts contacted by IATA regarding “use UNCEFACT for strongly typed data”.

Name Contact
Fred van Blommestein [email protected]
Groningen University
Faculteit Economie
ao. Univ.-Prof. Dr. Christian Huemer [email protected]<mailto:[email protected]
Vice Dean of Academic Affairs of Business
Informatics Vienna University of Technology
Michael Dill [email protected]<mailto:[email protected]
GEFEG mbH, Berlin
Frans van Diepen [email protected]<mailto:[email protected]
National Service for Enterprises
Ministry of Economic Affairs
Mandemaat 3 | 9405 TG | Assen | the
Netherlands
Kevin Smith [email protected]

MARY BLANTZ [email protected]

Sylvia Webb [email protected]

Page 41 of 41