Final Year Project Report

Web Services Technologies for

IATA’s New Distribution Capability (NDC)

Thibaud Durivaux

IATA Supervisor: Claude Muller

ISAE-Supaéro Supervisor: Christophe Garion

April – September 2018

 The airline industry is characterized by a wealth of IT systems and intercon-
nections between its various actors. Some of these solutions were revolutionary
when they were designed, before Internet even existed. Today, thanks to various
web services technologies, APIs are used in all industries. These technologies allow
for new solutions, such as IATA’s New Distribution Capability (NDC), which, as
a more modern communication standard, should bring significant improvements to
the airline distribution and payment landscapes.
The main question when such a standard is being developed is: how to design
it, and what technologies should be used? Adequacy for business requirements, ease
and speed of implementation, legacy systems, developers’ preferences are among the
decisive factors and have to be balanced.
This matter is the root of this report, in which several aspects of web services
are identified and studied in the context of NDC: data formats (XML and JSON),
API architecture paradigms (RPC and REST), and GraphQL, a recently designed
query language framework for APIs.
Acknowledgements

More than the mere report of part of my work during five months as NDC Architect
at IATA, this report is the embodiment of the end of an era, that of studies.
It is not only the final work towards my graduation from Supaéro, but also a sign
of the diversity I wish to have in my career. The subject of this report is out of my
comfort zone, and its applicability is in an industry I only started to discover during
my gap year at IATA. While challenging, this work is rewarding and instructive.
However, what matters most is the support and help of people around me. I
particularly wish to thank Claude Muller, who is a remarkable manager, and for
whom the best interest of his staff is always the highest priority.
I would also like to offer my special thanks to Vanni Sanvincenti, for his un-
waivering support, and Shaunelle Harris, who first guided me in the new world of
the airline industry.
More generally, all my colleagues from the NDC team (and beyond) have wel-
comed me and made my first significant work experience as enjoyable as it has been
so far, and I am very grateful for that.
Finally, on a more personal note, I would like to thank my parents and family,
for their constant and absolute confidence in me, and the few friends (you know who
you are) who really make a difference in my life.
Contents
Introduction 5
International Air Transport Association (IATA) . . . . . . . . . . . . . . . 5
Airline distribution and New Distribution Capability (NDC) . . . . . . . . 6
Airline Industry Data Model (AIDM) . . . . . . . . . . . . . . . . . . . . . 8
Role and Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 Data Formats for Web Services 10

1.1 Extensible Markup Language (XML) . . . . . . . . . . . . . . . . . . 10
1.2 JavaScript Object Notation (JSON) . . . . . . . . . . . . . . . . . . . 12
1.3 Technical comparison between XML and JSON . . . . . . . . . . . . 13
1.4 One standard, two data formats . . . . . . . . . . . . . . . . . . . . . 15
1.5 XML/JSON Two-Way Conversion . . . . . . . . . . . . . . . . . . . . 17
1.5.1 XML to JSON Conversion . . . . . . . . . . . . . . . . . . . . 19
1.5.2 JSON to XML Conversion . . . . . . . . . . . . . . . . . . . . 21

2 Web Services Paradigms 22

2.1 Legacy web services: Remote Procedure Call (RPC) . . . . . . . . . . 22
2.2 A different architecture: REST . . . . . . . . . . . . . . . . . . . . . 24
2.3 REST for NDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 A Query Language for Web Services: GraphQL 29

3.1 GraphQL paradigm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 General analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Current implementations . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 GraphQL for NDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1 General feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.2 NDC roles and GraphQL . . . . . . . . . . . . . . . . . . . . . 38
3.4.3 GraphQL driven by the AIDM . . . . . . . . . . . . . . . . . . 39
3.4.4 GraphQL as an evolution of message-based RPC . . . . . . . . 39
3.4.5 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Conclusion 44

Appendix 46
Example of AirShoppingRQ in XML and JSON . . . . . . . . . . . . . . . 46
AIDM I3 model of Passenger (18.1) . . . . . . . . . . . . . . . . . . . . . . 48
Extract of AIDM T3 model of AirShoppingRQ (18.1) . . . . . . . . . . . . 49
Extract of AirShoppingRQ.xsd (17.2) . . . . . . . . . . . . . . . . . . . . . 50
Prototype: GraphiQL IDE with a booking request . . . . . . . . . . . . . . 51
Introduction
International Air Transport Association (IATA)
IATA1 is a trade association, formed in 1945 in Havana, Cuba, currently representing
287 airlines (in 120 countries – August 2018) and 82 % of total scheduled air traffic2 .
Its headquarters are in Montreal, Canada, and executive headquarters in Geneva,
Switzerland.
IATA’s mission is to represent, lead and serve the airline industry. This translates
into a number of various activities, some of the most prominent ones being:

• helping airlines make their operations safer, particularly through the IATA
Operational Safety Audit (IOSA, used by more than 400 airlines, a third of
which are not even IATA members), and more secure, for instance with the
publication of the Dangerous Goods Regulation3 ;

• promoting environmental progress, especially through the support of the Car-

bon Offset and Reduction Scheme for International Aviation (CORSIA), first
global scheme covering an entire industrial sector, that has been agreed during
the 39th ICAO triennial assembly in 2016;

• being the voice of airlines for matters such as ATC organization and charges,
fuel cost, taxation, airports infrastructures and services;

• providing IATA Settlement Systems (ISS), a set of solutions that enables fast
and reliable money transfers within the industry (ISS settled $433.3bn in 2017);

• driving the modernization of Airline Industry Retailing (AIR) through four

main projects:

– New Distribution Capability (NDC) – air products retailing;

– ONE Order – order management modernization and simplification;
– NewGen ISS – modernization of ISS for even faster and more secure
distribution and settlement of funds;
– Transparency In Payment (TIP) – increased transparency and control in
the collection of sales.

IATA is organized4 in five regions (covering the entire world), the office of the
Director General (including Legal), and six divisions:

• Member and External Relations (MER);

• Financial and Distribution Services (FDS);

1
https://www.iata.org
2
measured in Revenue Tonne-Kilometers (RTK): revenue load (passenger and cargo weight)
multiplied by the distance flown
3
https://www.iata.org/publications/dgr/Pages/index.aspx
3
International Civil Aviation Organization
4
https://www.iata.org/about/Documents/iata-organizational-structure.pdf

5
 • Airports, Passenger, Cargo & Security (APCS);

• Safety & Flight Operations (SFO);

• Marketing & Commercial Services (MACS);

• Corporate Services.

The FDS division is itself organized in five departments, one of which, called
Transformation, is its innovation arm, comprised of new AIR (Airline Industry Re-
tailing) projects, such as NDC.

Airline distribution and New Distribution Capability (NDC)

Airline distribution is the way flights are sold to travelers (also known as passengers).
There are two ways of doing so: the direct channel and the indirect one. In the
direct channel, airlines sell flights through their websites (or call centers), directly
to passengers. There are no intermediaries, and airlines have full control over the
management, display, and sale of their offers.
The indirect channel dates back to the pre-Internet era, when direct contact
between airlines and travelers was difficult. This channel’s part in flight sales is
forecast to be 45% in 2021[5].

Figure 1: Airline distribution landscape before NDC5

In the indirect world, travel agents are the first intermediaries that travelers con-
tact. These agents (Online Travel Agents – OTA, Travel Management Companies –
TMC, . . . ) typically connect to one or several Global Distribution Systems (GDS)
in order to get flight offers. These GDSs (Amadeus, Sabre, and Travelport world-
wide, and TravelSky in China) rely on a design dating back to the end of the 1950s.
In general, they retrieve fares and schedules from third party databases (e.g. OAG
and ATPCo) and construct the offers that are provided to the travel agents. Once a
traveller asks an agent to make a reservation, the GDS contacts the airline directly
to confirm the availability of the selected offer. Then, the booking is performed by
a Passenger Service System (PSS), run by the airline or provided by an IT provider.
5
source: NDC Implementation Guide v4.2

6
 Figure 2: New airline distribution landscape5

NDC 6 – is a messaging standard (business model agnostic) intended to replace all

legacy communications between airline industry actors (except the end consumer).
With this new standard, airlines can be in total control of their offers and orders:
this give them the same control they have in the direct channel.
With NDC, offers are no longer constructed by third parties. Airlines can mer-
chandize their products directly (potentially through new distribution channels),
and even construct them in a personalized manner and/or with dynamic pricing.
This can lead to better product differenciation, as well as shorter time-to-market.
Similarly, airlines can manage their consumers’ orders, and can be in control of
the payment. NDC can also facilitate interlining7 and simplifies revenue accounting
as well as delivery, through another IATA project extending the NDC standard:
ONE Order8 .
Interestingly, this model of distribution is already what the low cost carriers use,
but without any industry-wide standardization.
In developer words, implementing NDC means creating a web API (Application
Programming Interface), or a set of web services: this is the interface used to interact
with partners by exchanging data. In this report, unless otherwise stated, all web
services implicitly use HTTP (HyperText Transfer Protocol)[7].
Currently, the NDC standard is a set of XML schemas (defined in more details
in the next section) defining messages, each one corresponding to a specific process
(shopping for offers, listing services, creating an order, . . . ).
In a simplified example scenario (illustrated in Fig. 3), when a customer consults
the website of an Online Travel Agent, an AirShoppingRQ (RQ for "request") mes-
sage is sent from the OTA to an aggregator, which in turn sends AirShoppingRQ mes-
sages to airlines. They respond with AirShoppingRS (RS for "response") messages,
containing several offers that are aggregated and sent in a single AirShoppingRS to
the OTA. If the consumer wishes to purchase one of these offers, an OrderCreateRQ
is sent to the relevant airline (through the aggregator), and an OrderViewRS is
returned to the OTA to confirm the order just created.
6
New Distribution Capability: https://www.iata.org/ndc
7
seamless passenger journey made of flights operated by different carriers but marketed by one,
thus driving a settlement process between these airlines
8
https://www.iata.org/oneorder

7
 Figure 3: Sequence diagram of a basic shopping and booking via NDC

Airline Industry Data Model (AIDM)

Because of the many standards IATA has to develop and maintain, and for the sake
of consistency, practicality, and speed of adoption, a new project has been created:
the Airline Industry Data Model (AIDM)9 . Its aim is to provide a common data
model (vocabulary, data definitions and relationships, . . . ) to all industry stan-
dards, including NDC, and also to offer a single methodology for the development
of standards. As of the 18.1 NDC release (in March 2018) the XML schemas are
generated from the data model which is the unique "source of truth".

Figure 4: AIDM principle10

9
http://www.iata.org/whatwedo/passenger/Pages/industry-data-model.aspx
10
source: official AIDM documentation

8
 This methodology is designed to bring agility to the development of new stan-
dards. Moreover, it can be applied regardless of the technologies involved. Models
can be re-used, independently of the platform, and they help bringing interoperabil-
ity across the industry.
The AIDM common repository is partitioned, as described in Table 1, around
3 pillars and 4 layers. The full methodology implies starting with the business
pillar, and progressively moving towards the information and then the technology
ones. Layers follow a top-down approach: contextual, conceptual, logical and then
physical.
For NDC, the most relevant models are I3, T3 and T4. I3 contains all the log-
ical information, for instance the description of a passenger (example provided in
appendix). This model is then imported into T3 – first non-platform-independent
step, in which unnecessary elements are removed and some technical adjustments
are made, such as the addition of containers to reflect the multiplicity in I3 (e.g.
Passengers containing Passenger elements). An extract of the T3 model for AirShop-
pingRQ is provided in appendix. Finally, message schemas (XSD) are generated in
T4.
Business Pillar Information Pillar Technology Pillar
Contextual B1 Value Chain, I1 Business Glossary,
Layer Business Objects, Ac- Information Domains,
tor & Localtion & Or- Taxonomy of Terms
ganization Catalogs
Conceptual B2 Business Process, I2 Conceptual Infor-
Layer Business Messages mation Models
Logical B3 Use Cases, Use I3 Logical Informa- T3 Logical Message
Layer Case Scenarios tion Models (Data En- Models
tities & all Attributes)
Physical I4 XML Library T4 XML Message
Layer Schema Model (com- Schema Model, WSDL
plex types) diagrams

Table 1: AIDM structure

Role and project objectives

Because of the various technologies available and some requests from companies
more used to a specific technology, IATA has to explore the different ways these web
services can be designed and implemented.
My role in this regard, as NDC Architect (NDC team, Transformation depart-
ment, FDS division), is to study and assess the various formats, concepts, and
architecture principles that can be used. The aim is to have factual comparisons,
evaluations of feasibility for NDC, and proofs of concepts when necessary.
Described further in this report are the two most common data formats (XML,
currently used for NDC, and JSON) and different architecture principles for NDC
APIs: the current RPC web services, RESTful APIs, and finally Facebook’s GraphQL.

9
1 Data Formats for Web Services
One important aspect of a web service is the way data is represented for transmis-
sion. The most common solution is to use text-based formats, because they are (to
some extent) both human- and machine-readable, making them fit for automatic
processing and easy (enough) to inspect.
In this section, the two data formats under consideration are XML and JSON.
Both are well-known and widespread, yet even though they can technically represent
any data, they do not provide the same functionalities or ecosystem. The NDC stan-
dard currently consists of schemas defining XML messages, but the standardization
of JSON messages is under consideration due to the request of some implementers.

1.1 Extensible Markup Language (XML)

XML (standardized by the World Wide Web Consortium11 [16]) is a text-based
data format, evolution of SGML – Standard Generalized Markup Language. It can
represent any type of structured information and it is, as such, used in a variety of
applications: to store information, to exchange data between programs or with a
web service, etc. About 20 years old, XML is ubiquitous and benefits from a rich
and mature ecosystem.
XML document example
1 <ExampleRQ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2 xsi:noNamespaceSchemaLocation="ExampleRQ.xsd">
3 <Departure>
4 <AirportCode>GVA</AirportCode>
5 <Date>2018-11-24</Date>
6 <Morning/>
7 </Departure>
8 <Arrival>
9 <AirportCode>TLS</AirportCode>
10 </Arrival>
11 </ExampleRQ>

The structure of an XML document is quite basic: elements, delimited by tags

(opening <Departure> and closing </Departure>, or empty <Morning/>), can have
attributes – which are often seen as metadata (for instance ExampleRQ.xsd is the
xsi:noNamespaceSchemaLocation attribute of ExampleRQ), and can contain a value
(e.g. GVA) or children (e.g. AirportCode and Date are children of Departure).
Elements have a specific namespace (similar to the package concept in Java for
instance); for clarity, this example uses the default namespace.

Most programming languages offer (natively or via a library) an XML parser,

which converts the XML document to an object that can be programmatically ma-
nipulated. For instance, the Document Object Model (DOM) is a W3C-defined
11
W3C: https://www.w3.org/

10
interface which gives access to the XML document with a tree structure (with the
notions of parent, child, sibling, ancestor, descendant, . . . ).
The retrieval of specific information in an XML document can also be facilitated
by the use of a specific query language: XPath (or even XQuery, a superset of
XPath). It basically describes the path to follow in the tree (which is a representation
of the data described by the XML) to reach particular elements. In the example
above, the XPath ExampleRQ/Departure/AirportCode leads to the element whose
value is GVA. In the rest of this report, XPaths will only refer to their simplest
form, a direct path to an element name (e.g. OrderCancelRQ/Request/BookingRef:
elements BookingRef in Request in root node OrderCancelRQ).

Another powerful tool accompanying XML is XML Schema Definition (XSD) –

newer and more expressive than Document Type Definition (DTD). An XSD docu-
ment, which is a particular type of XML document, defines the format ("schema")
an XML document must conform to.
An XML is said to be well-formed if it follows a simple set of rules, the main
ones being:

• single root element;

• valid characters;

• no overlapping elements;

• a closing tag for each opening tag.

An XML is said to be valid against an XSD if it has the proper structure (element
names, hierarchy, multiplicity, . . . ) and types (base types or custom ones, IDs and
references, . . . ). The concept of IDs and references to them (IDREFs) is quite
important: IDs must be unique, IDREFs must reference an existing ID, and Keys
and KeyRefs define which IDs can be referenced by which IDREFs.
The use of schemas is especially useful for developers wishing to use a third-party
API: XSDs provided by the API designers ensure that XMLs sent to this API are
acceptable. XSDs can be seen as a sort of contract for API consumers (definition
of what to send and what to expect in return). When used in conjonction with
namespaces (differentiating element names), several schemas can be used simulta-
neously. In the example above, ExampleRQ.xsd is the schema the document has to
be conform to.

One last example of the XML ecosystem is XSLT: eXtensible Stylesheet Lan-
guage Transformations. An XSLT document (which also is a particular XML one)
defines the transformations to be applied to an XML (making use of XPath) in or-
der to get, for instance, another XML (potentially defined by a different XSD), an
HTML web page, a PDF document, or a PNG image.

An example of an AirShoppingRQ (17.2) XML message is provided in appendix,

as well as an extract of the corresponding schema.

11
1.2 JavaScript Object Notation (JSON)
JSON (standardized by [11] and, with additional implementation considerations,
[9]), similarly to XML, is a text-based data format, about 15 years old, intended to
be easily read by both humans and machines. Derived from the JavaScript object
syntax, it is the most natural data format to be used with this programming lan-
guage. Part of its appeal comes from the fact that JavaScript can be used on the
end-consumer/client side (most websites use JavaScript today) and on the server
side (with NodeJS). However, JSON is not the only data format available for this
language (XML parsers exist for JavaScript too), and it is not limited to JavaScript
(most common programming languages provide JSON parsing and generation capa-
bilities).
JSON has the advantage of simplicity, with a lightweight syntax based on a
key:value structure. The key is a string, and the value can be one of the following:

• an object (delimited by {});

• an array of values (possibly mixed types) (delimited by []);

• a string;

• a number;

• a boolean (true or false);

• null.

The following simple JSON example does not reference any schema. Both this
one and the XML example (in the previous part) represent the same data; the empty
Morning element is arbitrarily represented as a null value for the Morning key.
JSON document example
1 {
2 "ExampleRQ": {
3 "Departure": {
4 "AirportCode": "GVA",
5 "Date": "2018-11-24",
6 "Morning": null
7 },
8 "Arrival": {
9 "AirportCode": "TLS"
10 }
11 }
12 }

However, compared to XML, this simplicity comes with some limitations.

JSON has a schema language (JSON Schema, [13]), currently in its 7th draft
version. Even though it can partly describe the structure (and types) of a JSON
document, it lacks some of the XSD capabilities.

12
 Generally, the most important features XML and its ecosystem provide that do
not have an equivalent in the JSON world are:
• namespaces;
• attributes (they semantically are metadata in XML, so not equivalent to child
elements);
• a query language similar to XPath;
• transformation definition such as XSLT;
• referential integrity (uniqueness of IDs, constraints applying to IDs or tokens
through Key and KeyRef12 );
• parity to UML (extensions and base types supported in XSD);
• more generally, and because of some of the points above, code generation.
Although JSON is unquestionably efficient for small (and simple) payloads, such
as those used in mobile apps, it may be harder to use in more complex applica-
tions because of the aforementioned limitations. In a nutshell, simple Business-
to-Consumer (B2C) applications are easily developed with JSON (especially when
JavaScript is used on both the user and server sides), but more complex Business-
to-Business (B2B) applications may require the full extent of XML capabilities.

1.3 Technical comparison between XML and JSON

JSON is often praised for its obvious simplicity and potential compacity, in addition
to the efficiency of its parsing (in JavaScript at least). This section sums up a short
technical comparisons between JSON and XML, space- and time-wise.
A set of 21 AirShoppingRQ/RS XML message pairs (taken from the certifica-
tion traces of 21 NDC-17.2 certified companies) was used as the XML samples for
this study; AirShoppingRQ (request for flight offers) and its subsequent AirShop-
pingRS (response with offers from the airline) are the first messages in a typical
NDC message flow. AirShoppingRQ, as all requests, is typically small, whereas Air-
ShoppingRS can be the longest message, because of the large number of offers it can
contain. This should give a good overview of XML/JSON differences in an NDC
context.
The JSON versions of these messages were generated by the tools described
later in this report. They carry almost the same information (see limitations of the
XML/JSON translation below).

First, the size needed to represent the same data in XML and JSON was com-
pared, between raw messages (Table 2) and compressed ones (Table 3). The com-
pression method used here is gzip13 because of its frequent and simple use by HTTP
services.
12
in the schemas, the Key designates primary keys, and KeyRef enforces what Key elements can
be referenced
13
http://www.gzip.org

13
 The advantage JSON has over XML is mitigated by compression, and is probably
not enough on its own to justify its use over that of XML, especially when a complete
RQ/RS cycle is considered.

XML size (bytes) JSON size (bytes) XML to JSON ratio

RQ 1,519 1,107 137 %
RS 223,992 200,562 112 %
Both 225,512 201,669 112 %

Table 2: Raw XML/JSON comparison

(averages over 21 AirShopping pairs)

XML comp. ratio JSON comp. ratio Comp. XML to JSON ratio
RQ 260 % 212 % 122.6 %
RS 1734 % 1621 % 107.0 %
Both 1671 % 1564 % 106.8 %

Table 3: XML/JSON compression ratio14 comparison – gzip

(average over 21 AirShopping pairs)

The next step was to measure the time required to perform deserialization (text
to object conversion) and serialization (opposite operation: object to text conver-
sion) in XML and JSON. This was done in two different languages (Python and
JavaScript in Node.js – server-side implementation), with the same set of messages,
over 1000 iterations for statistical significance.

In both language, the recorded processing time corresponds to the file reading,
deserialization, serialization and deletion of all variables. The results consists of
the average processing time µ, the 3-sigma confidence interval (99.7 % of values
assuming a normal distribution) and the p-value corresponding to the "XML and
JSON processing time are identical" null hypothesis.
Also in both language, file reading is done with the standard tools. The hardware
used to run those experiments (a standard Intel i5 SSD laptop) is not relevant since
there is no hardware acceleration for any of the operations needed here.
In Python (3.7), the lxml.etree module (available with pip) is used for XML,
and the standard json module for JSON.
In NodeJS (10.9), the xmldom library (available with npm) is used for XML, and
the built-in JSON functions for JSON.

Results show neither XML nor JSON are universally faster to process. Unsur-
prinsingly, JSON is better suited for JavaScript (Table 4), but XML is the best
choice for Python (Table 5). In both cases, the p-values are not necessary to reject
the null hypothesis because the confidence intervals do not overlap.
14 uncompressed size
compression ratio =
compressed size

14
 (s) µ 3σ
XML 0.849 0.259
JSON 0.124 0.010

Table 4: XML and JSON processing time in JavaScript

(s) µ 3σ
XML 0.104 0.010
JSON 0.219 0.024

Table 5: XML and JSON processing time in Python

The source code is available on GitHub:

https://github.com/airtechzone/xml-json-benchmarks.
In summary, for NDC messages, neither XML nor JSON has a significant ad-
vantage over the other, be it in terms of size (when compressed) or processing time
(for marshalling/unmarshalling).

1.4 One standard, two data formats

As NDC currently relies on XML and XSD, the question is: how can this standard be
extended to enable the use of JSON, without splitting it into two different standards?
As stated in the introduction, the NDC standard stems from the Airline Industry
Data Model. A first option is to generate JSON schemas the way XSDs are generated
today, from data model, with the use of Sparx’ software, Enterprise Architect. A
second option is to convert the XSDs to JSON schemas directly.

Figure 5: Initial Analysis

In both cases, because of the inherent limitations of JSON Schema described ear-
lier, it is likely that only a partial validation of JSON message files can be achieved.

15
Producing JSON Schema can be considered for informative purposes (with a clear
documentation of known limitations), but this is not as helpful as the full validation
capabilities of XSD.
Enterprise Architect supports the generation of XSDs (e.g. NDC schemas are
derived from the data model via this tool) and JSON schemas, but these two speci-
fications are not aligned. In the AIDM methodology, this would mean a different T4
model. This option would be acceptable if the goal was to provide a second JSON
standard stack, independent from the XML one.
The second option does not solve the issue of the first one. Besides, there is
no official conversion from XSD to JSON Schema, and implementations of such a
conversion necessary have arbitrary assumptions (for instance: [12]).
Altova recently released the XSD to JSON Schema conversion feature as part
of its commercial XMLSpy software15 . However, the XMLSpy solution has some
arbitrary choices built-in, and work-arounds that are not completely satisfying to
make the resulting JSON schema descriptive enough. For instance, namespaces are
simulated by the use of prefixes in the element names, like this: "ns:Passenger".
Such a convention does not reproduce the usual usefulness of namespaces, especially
in code generation. Of course, referential integrity is not enforced. As a side note,
attributes are siblings of the elements they are metadata of, and carry the @ prefix.
The third option, which is the one we chose, is to bypass completely any JSON
schema. Instead, we define an XML/JSON equivalence, and XSDs can be leveraged
for the validation of JSON messages: a JSON message is valid if, and only if, its
equivalent XML message is valid against its associated XSD. We also define conver-
sion tools which are reference implementations of the XML/JSON equivalence. All
this ensures there is no functional difference between the two data formats: there is
still only one NDC standard.

Figure 6: Proposal

15
https://www.altova.com/xmlspy-xml-editor

16
1.5 XML/JSON Two-Way Conversion
Because of the differences between XML and JSON, some conventions have to be
adopted, and some metadata are required for this two-way conversion.
First of all, because XML can have several elements with the same name but
JSON cannot have two identical keys at the same level, multiplicity in XML is
translated with arrays in JSON. However, the rule to determine whether an element
should be a single object or an array of objects has to be independant from the
context, and thus has to come from the XSDs. Therefore, we define that an element
is an array in JSON if, and only if, the maximum number of occurences (maxOccurs)
defined in the XSD is not equal to 1 (implicitly or explicitly). In the following
example, Passengers has maxOccurs="1" and Passenger is unbounded (maxOccurs=
"unbounded") in the schema.

JSON
XML 1 {
1 <Passengers> 2 "Passengers": {
2 <Passenger> 3 "Passenger": [{
3 ... 4 ...
4 </Passenger> 5 },
5 <Passenger> 6 {
6 ... 7 ...
7 </Passenger> 8 }]
8 </Passengers> 9 }
10 }

In more details, an XML element becomes a key:value pair in JSON: the key is
the element name (its XML tag), and the value is either a single object or an array
of objects. These objects (instances of the element) can contain:

• attributes in a object named $

• the value of the element, named _ (cannot coexist with children)

• one child or more (cannot coexist with the value).

As a general rule, only the string type of JSON is used (whatever the type in XSD).
In the following examples, root and child1 have a maximum multiplicity of
one, unlike element and child2.

17
 JSON
1 {
2 "root": {
3 "element": [
4 {
5 "$": {
6 "attr1": "a"
7 },
XML 8 "_": "content"
9 },
1 <root>
10 {
2 <element attr1="a">content<
11 "$ ": {
/element>
12 "attr2": "b",
3 <element attr2="b" attr3="c
13 "attr3": "c"
">
14 },
4 <child1>...</child1>
15 "child1": {
5 <child2>...</child2>
16 ...
6 </element>
17 },
7 </root>
18 "child2": [
19 {
20 ...
21 }
22 ]
23 }
24 ]
25 }
26 }

With this definition, the XML and JSON documents contain almost the same
amout of information. The missing data are:
• the order of elements in JSON (because an object is a set), and
• the maximum multiplicity of each element being one or more in the XML.
To address this gap, metadata are required for the conversion process. They are
generated once (and then provided as static resources for the conversion process)
from the official XSDs with the help of a custom Python script that browses (depth-
first) the tree structure of the schemas.
The source code is available on GitHub:
https://github.com/airtechzone/xml-json-metadata-generation.
This equivalence has been designed with XML as a starting point, and is aiming
at simplicity and explainability. This is why the resulting JSON documents could
have a better design, but any improvement would be at the cost of the aforemen-
tioned qualities.
An example of the AirShopppingRQ message in both XML and JSON is provided
in appendix.
Both conversion tools are implemented in Node.js for simplicity, but a high per-
formance prototype in C++ has been developed for the XML to JSON conversion.

18
They are reference implementation for the bidirectional conversion, but only for
strictly valid inputs since they only feature a limited exception handling.
The source code can be found on GitHub (links provided below), and an online
version is available (in JavaScript on the client side, with a graphical user interface)
on IATA’s AIR Tech Zone:
https://airtechzone.iata.org/toolbox/tools#xml-json.
Besides, a JSON NDC sandbox has been created with the help of a conversion layer
on top of the regular XML NDC sandbox; details to get access to this JSON NDC
sandbox can also be found on AIR Tech Zone:
https://airtechzone.iata.org/toolbox/ndc-sandbox#howto

1.5.1 XML to JSON Conversion

The XML to JSON conversion leads to the loss of the order of elements in sequences,
but that is not necessary for data processing. This conversion requires metadata to
determine whether elements are singletons (maximum occurence of 1) or not. This
is provided by a JSON file containing the list of XPaths of exactly all singletons
elements.
The XML file is parsed and its tree structure is browsed depth-first (while keeping
track of the current XPath), and the JSON output is written on the fly during this
process. There are three steps for each element:
• process attributes (if there are any, add the $ key with the value being the
object containing all attributes);
• process the value (if there is one, it is added with the _ key);
• process children:
– if a child’s XPath is in the singletons list, then an object is used;
– otherwise, all children with the same name are represented in an array.
The source code is available on GitHub:
https://github.com/airtechzone/ndc-xml2json-js.
The following algorithm is a proof of concept that demonstrates how time- and
memory-efficient an XML-to-JSON conversion tool can be. It has been implemented
in the low level programming language that is C++ with this efficiency in mind. On a
regular laptop (Intel i5 5th generation at 2.2 GHz, SSD), a 8000-line AirShoppingRS
(400 kB) is processed in less than 20 ms. By comparison, simply parsing this XML
file in NodeJS takes more than 60 ms.
Yellow outputs are chosen over the grey ones if, since the last state 1, state 2
has been encountered.
The design of this algorithm is a state machine that reads, character by character,
the XML file, and produces the JSON one on the fly. This design ensures a linear
time complexity and a constant space one. The buffered reading and writing can be
used as a way to manage the trade-off between processing time and memory usage:
the bigger the buffer, the more memory is used, and the less computation time is
required (because RAM access is faster than filesystem access).

19
 Figure 7: State machine diagram for an efficient XML to JSON conversion

Extract of singletons-172.json
1 [
2 "Acknowledgement/",
3 "Acknowledgement/Document/",
4 "Acknowledgement/Document/Metadata/",
5 "Acknowledgement/Document/Name/",
6 "Acknowledgement/Document/ReferenceVersion/",
7 "Acknowledgement/StatusCode/",
8 "Acknowledgement/StatusMessage/",
9 "AirDocDisplayRQ/",
10 ...
11 ]

20
1.5.2 JSON to XML Conversion
The conversion from JSON to XML requires the retrieval of the order of elements
inside sequences. This is provided by a JSON file in which keys are the XPaths of
all sequences described in the XSD, and values are arrays of elements’ names in the
order they have to be in the sequences. The loss of the singletons information is
irrelevant for data processing.
This algorithm is very similar to the previous one. The only important difference
is that before processing children, all the keys (except, if present, $) are sorted
according to the sequences metadata; if the current XPath (strictly speaking, that
of the XML being constructed) is not known, then keys are left as-is. Besides, for
each element being processed, its type has to be assessed first: array (recursive
processing its items) or not.
The source code is available on GitHub:
https://github.com/airtechzone/ndc-json2xml-js.
Extract of sequences-172.json
1 {
2 "Acknowledgement/Document/": ["Metadata", "Name", "
ReferenceVersion"],
3 "Acknowledgement/": ["Document", "StatusCode", "StatusMessage"],
4 "AirDocDisplayRQ/PointOfSale/Location/": ["CountryCode", "
CityCode"],
5 "AirDocDisplayRQ/PointOfSale/TouchPoint/Device/": ["Code", "
Definition", "TableName", "Link", "Position"],
6 "AirDocDisplayRQ/PointOfSale/TouchPoint/Device/Position/": ["
Latitude", "Longitude", "Altitude", NAC"],
7 "AirDocDisplayRQ/PointOfSale/TouchPoint/": ["Device", "Event"],
8 "AirDocDisplayRQ/PointOfSale/": ["Location", "RequestTime", "
TouchPoint"],
9 "AirDocDisplayRQ/Document/": ["Metadata", "Name", "
ReferenceVersion"],
10 ...
11 }

21
2 Web Services Paradigms
As shown in Fig. 8, NDC is one of the 3 channels of communication with an airline:
• legacy messages (EDIFACT), mainly used by GDS (see Fig. 1);

• "airline.com" i.e. the airline’s online website;

• NDC API.
The NDC API is the interface travel agents/aggregators (as well as other airlines,
in case of NDC interlining) use to interact with the airline. This API gives access to
the integration layer, which brings together all the business functions (potentially
provided by third parties) of the airline. The design of this API has therefore to be
both practical for clients and fit for the airline internal functions at the same time.

Figure 8: Reference architecture for airlines5

2.1 Legacy web services: Remote Procedure Call (RPC)

One of the earliest type of API interaction is RPC, or Remote Procedure Call. As
its name implies, it consists in calling (executing) a procedure (function/process)
remotely (on a distant server). For a web API, it means that, like a function that
can be called in a program, an HTTP call is used to perform some action on a server.
This is a service oriented architecture (SOA).

22
 The NDC standard describes a very simple RPC API: only XML request and
response messages are defined (with XSD), and no transport protocol is specified.
The XML schemas are extremely precise, thus enforcing a consistent and predictable
usage of the API. Concretely, making a request means sending an XML request via
HTTP (so-called POST request) to the API endpoint, and getting back an XML
response.
RPC is underpined by processes: a message is a process. A few examples in
NDC:

• AirShoppingRQ/RS is the query (with filters/qualifiers) of offers from the

airline;

• ServiceListRQ/RS is the query (with filters/qualifiers) of applicable ancillary

services for a given flight;

• OrderCreateRQ/OrderViewRS is the selection of offers and subsequent cre-

ation of an order;

• OrderChangeRQ/OrderViewRS is the modification of an existing order.

There are several specifications based on the RPC concept, such as XML-RPC
and JSON-RPC (seldom used) and SOAP.
Originally "Simple Object Access Protocol", SOAP is an RPC protocol independent
of the transport protocol, but it is mostly used over HTTP. A SOAP API is usually
defined by two elements:

• the XML schema (XSD) of the payload, i.e. the body of the message, and

• the description of the service with WSDL (Web Service Description Language).

The WSDL can be seen as the function signature of the web service, and it is all
that is needed to understand how to communicate with the service. It provides all
the metadata required to fully create and interpret messages for and from such a
service.
As a side note, no WSDL is provided by IATA for NDC, as it is up to the vendors
to choose the form of their implementation, but it can be easily generated from the
AIDM T4.
One major advantage of SOAP is its security extension, WS-Security16 , which
enables the protection of the message exchange confidentiality and integrity. It is
a well-known and trusted solution frequently used in sensitive applications such as
banking.
In general, RPC protocols, such as SOAP, lead to a tight coupling between the
server and the client. Indeed, the slightest modification on the server side (which
implies a change in the WSDL) has to also be applied on the client side.
16
Web Service Security: http://docs.oasis-open.org/wss-m/wss/v1.1.1/os/
wss-SOAPMessageSecurity-v1.1.1-os.html

23
2.2 A different architecture: REST
A newer approach for the design of APIs (more and more popular for public ones)
is REST, or REpresentational State Transfer (first described in 2000: [4]). While
RPC is function-driven, REST is resource-oriented: instead of defining processes,
RESTful APIs give CRUD (create, read, update, delete) access to resources, i.e. the
data itself ([15], [14], [1]).
While typically used in conjonction with JSON, REST does not impose any data
format.
The fundamental principles of REST are as follows:
• client-server communication;
• layered system: intermediary servers may be used, without the client notic-
ing;
• cacheable: concept of resource lifecycle (validity for a certain period of time),
which can be applied with the HTTP cache control methods;
• stateless: no client context is stored on the server between requests;
• uniform interface: resources are identified by URIs17 and can be manipu-
lated through their representations.
In addition to the uniform interface concept, hypermedia is a core feature of a REST-
ful web service. Known as HATEOAS (Hypermedia As The Engine Of Application
State), this concept is characterized by the use of hyperlinks in responses for extra
information or actions. For instance, a flight offer could contain a service which
is further described at another location, with the relevant URI provided in the re-
sponse. Similarly, a link to a third-party payment page could be given as a "next
available action".
Instead of redefining several features, REST makes use of those already provided
by HTTP, such as verbs and status codes.
HTTP verbs are the description of the type of request. In a RESTful API, they
are used to denote the four CRUD operations, as described in Table 6.
POST Create a new resource (executed on a collection of resources)
GET Retrieve an existing resource, or, when executed on a collec-
tion, a list of resources (the resources remaind unchanged)
PUT Update an existing resource (idempotent operation: executing
it twice yields the same result)
DELETE Delete an existing resource, or all resources in a collection

Table 6: HTTP verbs for CRUD

HTTP status codes are a simple way to convey the status of the request, without
any need to parse the response. Some examples of common status codes used in a
RESTful API are shown in Table 7.
17
Uniform Resource Identifier: a string that refers to a resource; for instance, URLs (Uniform
Resource Locator) are URIs accessible over a specified protocol, such as HTTP or HTTPS

24
 200 OK Standard code for a successful request
201 Created A new resource has been created
400 Bad Request Client error in the request
401 Unauthorized Access token not provided or invalid
403 Forbidden Insufficient privileges
404 Not Found The requested resource cannot be found
500 Internal Server Error Unexpected error on the server side

Table 7: Examples of HTTP status codes

RESTful APIs are most commonly described with the help of the OpenAPI
Specification (OAS)18 . It enables the full description of the resources that the API
can manage, as well as the operations that can be performed. Moreover, an accom-
panying set of tools facilitates the automatic documentation, code generation, and
testing.

2.3 REST for NDC

In this section, the feasibility of designing a RESTful NDC API is studied. In order
to keep the consistency with the current RPC NDC, this RESTful API is seen as
an evolution of the RPC services.
The transition from processes (RPC) to resources (REST) can be modeled by the
Richardson Maturity Model.

• Level 0 – HTTP as a transport protocol

– Single entry point for the API

– Only POST requests
– All responses have a "200 - OK" status code
– The context of the result is only found in the actual message payload

• Level 1 – Concept of resources

– Resources are defined, and identified by URIs

– Still only POST request and "200 - OK" response status code

• Level 2 – HTTP methods and error codes

– Use of other HTTP verbs (GET, PUT, DELETE)

– Use of HTTP response codes (the payload is no longer required to un-
derstand the high-level status of the response)

• Level 3 – Full HATEOAS compliance

– Hypermedia controls, making the API more self-documenting

18
https://www.openapis.org/, coming from Swagger: https://swagger.io

25
So far, a basic implementation of the NDC standard is clearly at level 0. For
instance, the IATA NDC sandboxes19 each have a single endpoint (fake Kronos
airline – IATA code C9: http://iata.api.mashery.com/kronos/ndc172api) for
all supported NDC message pairs. They are sent via a HTTP POST request, and
errors are described in the response payload only. For instance, a request for a flight
from AUH (Abu Dhabi International Airport) to TLS (Toulouse Blagnac Airport)
yields the following response (stripped of irrelevant metadata at the root level) with
the "200 - OK" HTTP status code.
1 <AirShoppingRS>
2 <Errors>
3 <Error Owner="C9">Airline does not operate at requested
Departure airport: AUH</Error>
4 </Errors>
5 </AirShoppingRS>

The natural approach to the design of a RESTful NDC API is to first define what
the resources are. Loosely based on the initial Business Requirements Documents20
(BRDs) of NDC, the basic structure of the API could look like:
http://ndc.iata.org
/offers
/orders
/bookings
/payments
/fulfillments
/settlements
/operations
/flightstatus
/schedules
/references
/aircrafts
/airlines
/airports
/cities
/countries
With the help of the data model, it is possible to further break down resources
into smaller entities. NDC already relies on unique identifiers (IDs), which trans-
late well into a resource-oriented view. As an example, an order with the booking
reference ABC-456-GHI would be identified by:
http://ndc.iata.org/orders/bookings/ABC-456-GHI,
passengers referenced by this booking by:
http://ndc.iata.org/orders/bookings/ABC-456-GHI/passengers,
and a specific passenger (whose ID is P123456789):
http://ndc.iata.org/orders/bookings/ABC-456-GHI/passengers/P12345678.
19
https://airtechzone.iata.org/toolbox/ndc-sandbox
20
first step of the definition of a standard, before any technical consideration

26
 Query parameters can also be used, especially in GET requests for data retrieval,
such as shopping for a flight: ?cabin=business&direct=true. This helps keeping
URIs shorter and simpler to use.
Granularity in the definition of resources helps getting the most benefits from
HATEOAS: instead of including all the details of a resource, links to sub-parts of
it can be used. For instance, an order can link to passengers, flights can link to
available services linking, in turn, to rich media for an enhanced description. . .
In general, the retrieval of information is simpler to design and implement than
the modification processes. More complex business functions, such as those en-
countered for servicing (order management phase), do not map to HTTP methods
in a simplistic CRUD manner. This particularly affects the processes provided by
servicing messages: OrderReshopRQ/RS, OrderChangeRQ/OrderViewRS, and Or-
derCancelRQ/RS.
The naive idea of directly modifying sub-resources in an order does not usually re-
spect the constraints of such operations. For instance, changing a passenger in an
order is not as straightforward as making a PUT request on the resource repre-
senting that passenger, because the order has to be changed in agreement with the
airline, and potentially entails other changes to the order (e.g. fees). There can be
work-arounds for this kind of problem, as explained below, but they all have some
shortcomings.
A first solution would be to create special sub-resources on which the actions
are executed, as if the new requests were added to a queue for processing. In the
previous example, a way to check-in a passenger would be:
http://ndc.iata.org/orders/bookings/checkin
/ABC-456-GHI/passengers/P12345678.
This solution is already closer to an RPC style than to a REST one, and may not
be enough in more complex use cases, such as servicing.
A second solution would require the client to know much more in order to use the
API. A complex action could be interpreted as a pre-agreed series of REST actions,
but this would increase the difficulty to use the API significantly, and client and
server would be more tightly coupled, like they would be for an RPC API. More
concretely, today’s NDC schemas are partially self-explanatory, and classic use cases
can be easily implemented based on those schemas or on XML samples. A developer
implementing these classic use cases with a REST API would have to read much
more external documentation, such as the implementation guide.

For complex B2B scenarios such as those NDC addresses, the flexibility and
modularity of REST come at the expense of business rules enforcement. Because of
that, other industries with complex business functions stick to XML and XSD. For
instance, ACORD21 provides a set of XML standards for the insurance industry22 ,
and most banking systems rely on XML: FpML23 , SWIFT24 , etc.
21
Association for Cooperative Operations Research and Development
22
https://www.acord.org/standards-architecture/acord-data-standards
23
Financial products Markup Language
24
Society for Worldwide Interbank Financial Telecommunication

27
 Besides, if such an architecture (without any trade-off) is deemed desirable for
NDC, another issue arises: because of the focus shift from processes to resources, the
processes are broken down into smaller functions, and part of the business logic is
lost. This means a truly RESTful NDC API concept would be a different standard
altogether.
However, some interesting concepts from REST can be adapted to NDC. On the
Richardson Maturity Model, the level 1 can be achieved (if a single standard is to
be preserved) with resources only being the higher level processes of offer and order
management, and the exclusive use of the POST method.
HTTP status codes could be used to give a general idea of the outcome of a request,
partially eliminating the need to parse the response payload in some cases (request
accepted with no additional information to be returned, error due to privileges issues,
. . . ). Finally, responses can be made lighter with the use of hyperlinks, especially
with static content such as services and their descriptions.

28
3 A Query Language for Web Services: GraphQL
GraphQL [3] has been developed by Facebook since 2012, first as the API driving
their mobile app, then made public in 2015 and developed with the help of the
community ever since. It replaces older APIs of different flavours, partially REST
or fully RPC, such as FQL25 , no longer supported as of 2016.
GraphQL can be summarized as RPC with some concepts from REST, in par-
ticular that of resoures [10]. Similarly to all previously described API paradigms,
it is programming language agnostic and contract-based: what the client can re-
quest to the server is perfectly defined, as is the response to be expected, with the
particularity that the response is entirely shaped by the request.
The main reasons for the development of this new API framework are its sim-
plicity and flexibility, the separation between front-end and back-end development,
and the solving of the under- and over-fetching issues other types of APIs can have.
GraphQL is designed to be lightweight (especially for mobile usage, where efficiency
in data exchange is essential) and to enable a faster and more flexible evolution of the
API. Also, its specification is precise enough not to have too broad interpretations,
unlike REST.

3.1 GraphQL paradigm

GraphQL is a specification26 , which has official implementations in all major pro-
gramming languages. A GraphQL API has a single endpoint, and is most commonly
used over HTTP (usually compressed with gzip). Both GET and POST methods
should be supported, offering the same functionalities. The request is either a query
string (e.g. http://ndc.iata.org/graphql?query=...) for GET or inside the
payload for POST, as follows. operationName can specify which operation to per-
form if several are provided in the query, and variables can be used to avoid
redundancies in query.

1 {
2 "query": "...",
3 "operationName": "...",
4 "variables": { "var1": "value", ... }
5 }

The only procedure available is the processing of the query language (which is in-
spired by JSON, but even simpler), and the response is in JSON. The returned
object contains a data object, and, in the case errors occured, an error array (data
potentially set to null).

1 {
2 "data": {
3 ...
25
Facebook Query Languge; it consisted in making SQL requests over HTTP, SQL query strings
being passed as HTTP GET query parameters, with a JSON-formatted response
26
https://facebook.github.io/graphql

29
 4 },
5 "errors": [
6 ...
7 ]
8 }

The main and most appealing concept of GraphQL is that the client’s request
entirely describes the response. The information retrieved is exactly what was re-
quested, structured in a fully predictable way. Below is an example (inspired by [2])
of a GraphQL query and its subsequent response.

1 query {
2 allPersons {
3 name
4 age
5 }
6 }

1 {
2 "data": {
3 "allPersons": [
4 {
5 "name": "Alice",
6 "age": 24
7 },
8 {
9 "name": "Bob",
10 "age": 42
11 }
12 ]
13 }
14 }

A GraphQL API is based on two elements:

• a schema, written in the Schema Definition Language (SDL), providing a data

model of the available resources and describing the queries clients are allowed
to make;

• resolvers, i.e. functions the server uses in order to process a query, either to
retrieve information or to perform an action, as defined by the schema.

Thanks to this schema, GraphQL has a self-introspection capability: the API can
be queried to discover what queries can be made. Some tools, such as GraphQL
Voyager27 , can create a graphical representation of the data model, based on this
introspection query.

27
https://github.com/APIs-guru/graphql-voyager

30
 Here is a brief overview of SDL. The built-in types are:

• Int – signed 32-bit integer;

• Float – signed double-precision floating-point number;

• Boolean – true or false;

• String – UTF-8 character sequence;

• ID – similar to String but representing a unique identifier.

Other types can be defined with the scalar keyword, but no further indication
can be provided in the schema. SDL also has enumerations (enum) and unions of
types (union); the response can be shaped differently depending on the actual type
used with a so-called inline fragment: ... on actualType { ... }. Similarly,
interfaces (abstract types) can be defined (interface) and used when different types
share some fields: those fields can be requested directly, and inline fragments can
specify the request for more specialized fields.
A field can also be defined as an array (ordered collection of elements): in this case,
the type of the array elements is put inside brackets, e.g. [String].
By default, all fields are nullable, i.e. can be returned as null (this can be used
to avoid errors). To prevent that, an excalamation mark can be added in the schema
after the type of the field (e.g. String! or [String]!), or after an array element
type so that no element in the array can be null (e.g. [String!]).

The schema represents the data structure as a graph (as opposed to a tree, in
the case of XSD for instance). The following simple schema example illustrates a
one-to-many relationship between Person and Post. A many-to-many relationship
would require Post to have a field typed [Person].

1 type Person {
2 id: ID!
3 name: String!
4 age: Int!
5 posts: [Posts!]!
6 }
7

8 type Post {
9 title: String!
10 author: Person!
11 }

31
 Besides the data model, the schema defines the available operations which are
of one of the three following types:

• query, simply for fetching/reading data;

• mutation, for modifying data (creation, update, deletion);

• subscription, for initiating a steady connection with the server which can
then push changes to the client.

1 type Query {
2 allPersons(last: Int): [Person!]!
3 }
4

5 type Mutation {
6 createPerson(name: String!, age: Int!): Person!
7 }
8

9 type Subscription {
10 newPerson: Person!
11 }

All these operations can have arguments, either of built-in types, or of the special
input type. The latter is defined as any other custom type, thus with as complex as
necessary. Besides, the request (not only for a query) always contains the structure
of the expected response, which can then describe the outcome of a mutation.
For instance, the ID of a new resource can be requested upon its creation.

1 mutation {
2 createPerson(name: "Bob", age: 42) {
3 id
4 }
5 }

1 {
2 "createPerson": {
3 "id": "P12345678",
4 }
5 }

The architecture of a GraphQL API, as represented in Fig. 9, clearly separates

the front-end and the back-end, and help masking the underlying operation of the
API. The client only interacts with the API according to the schema. For each oper-
ation and type a resolver function is implemented on the server side: the GraphQL
query can be seen as a tree of resolver function calls. The GraphQL implementa-
tion takes care of these function calls, so developers only need to program these
functions. The processing can be done directly on databases (most commonly) or
through other APIs (or both); back-end processes do not influence the front-end.

32
 Figure 9: Typical GraphQL API architecture

3.2 General analysis

As stated above, GraphQL enables a clear separation between front-end and back-
end, with the schema as the interface between the two. This loose coupling con-
tributes to the ease of independent development of both sides. Also, maintaining
smaller resolver functions is potentially easier, and the variety of data sources can
be handled without any extra abstraction layer.
Thanks to the extremely granular structure, detailed analytics of API usage
can constructed. This gives a precise view of clients’ needs, which helps deciding
how to make the API evolve (deprecation of unneeded features for instance) as well
as monitoring the performance and adapting the infrastructure accordingly. Such
a thorough and fast feedback is not available with classical RPC or, to a lesser
extent (because of the increased granularity of resources compared to processes),
with REST APIs.
GraphQL also serves exactly the content requested by the client. Unlike REST
and RPC, whose responses may contain much more information than needed (be-
cause of their fixed structure), this type of API has no over-fetching issue.
The under-fetching issue is also virtually eliminated because all the data is rep-
resented in a single graph and one response can contain everything the client need,
with only one request. RPC can have that issue, but it is particularly prominent
for REST, because of the way resources are defined and because of the HATEOAS
principle. A large number of calls is required to fetch all necessary data; this is for
instance the "HTTP n + 1" issue: in order to get all n resources in a collection, a
first call yields the URIs of each resource, and n calls are needed to get them, one
at a time. However, this issue is resolved with HTTP/2 ([8]), thanks to its reduced
overhead and fully multiplexed connections which allow a better parallelism.

33
 The kind of request made with GraphQL is a type of declarative data fetching,
where everything is handled by the API as long as the data requested is described,
as opposed to imperative data fetching, where the request has to be constructed by
the client and the response parsed and interpreted.
In addition to those advantages, the ability to select the content of the response
can help reducing the server load, simplifies the development of the client side, and
makes the need to create new processes (in RPC) or endpoints (in REST) more rare.
It stays necessary only for different mutations or additional parameters in queries.

On a theoretical level, [6] provides an analysis of the general complexity of

GraphQL processing. Even though the size of the response increases exponentially
with the size of the request, the main decision problem (is a response valid for a
given request and a graph? ) is NL-complete (nondeterministic logarithmic space).
Because NL is a subset of P (deterministic polynomial time), it can be solved in
polynomial time.
Anyway, security strategies are needed to prevent too large queries, such as:
• timeout;
• maximum query depth (may be insufficient);
• rejection of query based on their complexity (estimated before execution);
• throttling based on time or complexity.
In the example illustrated by Fig. 10, a maximum depth of 3 or a maximum
complexity (as defined in this simple example) of 20 would block this request. Here,
it is assumed an age is more complex to retrieve than a name, as is a pet compared
to a friend. Arguments such as the number of elements requested can be taken into
account.

Figure 10: Examples of metrics: depth and complexity

34
3.3 Current implementations
Originally developed by Facebook, GraphQL is at the core of the Facebook mo-
bile apps. It is used in conjunction with React Native28 (React29 for mobile apps,
developed by Facebook), the Relay framework30 bridging the two technologies.
Several companies (a significant number of them, given how recent the technology
is) use GraphQL: Club Med, Coursera, Dailymotion, GitHub, NBC News, The New
York Times, Twitter, Yelp, to only cite a few.
GitHub has been the first major company to offer a public GraphQL API31 .
They always provided an API to interact with their data, the third version of which
was a RESTful API32 (with full hypermedia capability). The main issues they had
with it were:

• too many transactions – the REST API generated 60 % of the database re-
quests;

• bloated responses;

• complexity on the client side – especially because several calls were necessary
for one operation;

• no automatic generation of code documentation or client code.

After trying GraphQL on a small service (react with emojis to comments), it became
the basis of the fourth version of their API, but with limited functionalities compared
to the third one. Today, REST and GraphQL coexist, GitHub seeing them as two
different work streams.
Yelp also offers a public GraphQL API33 alongside a more traditional one (Yelp
Fusion API34 ), but both have the same functionalities. They only provide data
retrieval features. Yelp Fusion consists of a set of endpoints used with HTTP GET
requests (more RPC than REST), and the GraphQL API only offers queries (no
mutation or subscription).
The REST APIs of Coursera have the same kind of issues described above,
but because of their number (and all the systems and clients depending on them),
replacing them would have been too expensive. This is why Coursera’s GraphQL
APIs are automatically generated from the REST ones: the development cost is
minimized (because this process is relatively simple35 ) and front-end developers can
benefit from GraphQL.
28
https://facebook.github.io/react-native/
29
JavaScript library for the creation of "reactive" user interfaces: https://reactjs.org/
30
https://facebook.github.io/relay/
31
https://developer.github.com/v4/
32
https://developer.github.com/v3/
33
https://www.yelp.com/developers/graphql/guides/intro
34
https://www.yelp.com/developers/documentation/v3/get_started
35
https://graphql.org/blog/rest-api-graphql-wrapper/

35
3.4 GraphQL for NDC
3.4.1 General feasibility
Because GraphQL is an RPC framework, it is a more natural fit for NDC than
REST. Even though the concept of resources exist in GraphQL, operations are not
directly performed on them in a CRUD manner: business logic can therefore be
preserved.
As a general consideration, information retrieval is easier to design and imple-
ment than any other operation involving changes. In the case of GraphQL for NDC,
this means that the conception of queries should be more straightforward than that
of mutations. Subscriptions, which can be seen as change-triggered queries, do not
present additional data modeling and process defining difficulties.
The shopping part of NDC consists in fetching data, therefore messages such
as the following can be translated into GraphQL queries, provided the required
elements are given as arguments of those queries:
• AirShoppingRQ/RS;
• OfferPriceRQ/RS;
• SeatAvailabilityRQ/RS;
• ServiceListRQ/RS.
Because only a subset of XSD contraints can be defined in SDL, the GraphQL
API either only provides a subset of the NDC requests functionalities, or does not
give its own full specification. In the latter case, external information is required,
such as a very detailed implementation guide, or simply a description of how to
interpret NDC schemas for GraphQL queries. Any invalid query would lead to
errors, ideally informative enough to correct the query mistakes, but this would
imply even more complexity on the server side: not only correct queries have to
be processed, but incorrect ones would have to be matched to their closest valid
variant, with a description of the difference.
The ordering and servicing part has the additional complexity of changing data
(through well-defined processes) on the airline side. Messages such as the following
have to be mutations in a GraphQL API:
• OrderCancelRQ/RS;
• OrderCreateRQ/OrderViewRS;
• OrderChangeRQ/OrderViewRS.
Their arguments’ structure and completeness are absolutely required, more so
than for simple queries. Returning an error because of an incorrect input is still
feasible. To avoid too frequent errors, it is also possible to limit the available opera-
tions to fewer cases. Indeed, without the richness of XML schemas, either GraphQL
schemas allow too diverse inputs (hence the return of errors), or they simplify them,
obliterating more complex functionalities and cases.

36
 The subscription mechanism of GraphQL is a solution for the ongoing issue of
involuntary servicing. There is a debate today about how NDC implementations
should manage, for instance, a cancelled flight. The OrderChangeNotif (RQ, as of
18.2), intended for this purpose, is the only message originating from the airline, but
it is not clear yet what mechanism should be used for it, or even whether it should be
in a push (airline contacting the seller, more likely) or pull (the other way around)
manner. In a GraphQL API, the natural solution is to use subscriptions: with a
direct seller-airline communication, the seller subscribes to every order it manages,
so that it gets informed of any involuntary changes immediately, without any action
on its part.
In all cases, the responses requested have to include important fields for the next
steps of the flow, for instance IDs. It is up to the client to be mindful of that,
because the server cannot choose to add unrequested results.

While the principles of GraphQL fit well to NDC, thanks to its RPC style, the
main challenge is the use of its Schema Definition Language, inherently less detailed
than XSD.
From now on, there is a distinction between the response query, i.e. the structure of
the response that is requested by the client; the query arguments, i.e. the arguments
of the root query; and the arguments of sub-queries, i.e. the parameters used (under
the root query) to further describe the expected response.
Besides the built-in types, SDL cannot describe more complex ones, for instance
a string constrained by a regular expression. Even though it means the GraphQL
API is not fully self-documented, it is not a functional issue: the response can be
queried anyway. On the other hand, the arguments of queries, which should ideally
reflect the RQ messages, cannot be defined well enough to ensure their processing is
possible. External documentation is a solution (especially in order to keep a single
consistent standard), or the queries have to be adapted to GraphQL.
Structurally, multiplicity can be represented by arrays, but minima and maxima
cannot be enforced in SDL. Unions can be used to represent choices. A major
difference between an XML message and a GraphQL one is the use of IDs: in order
to avoid data duplication, NDC messages have so-called DataLists, containing, for
instance, flights segments, passengers, and service definitions, all uniquely identified
by IDs. These elements are referenced elsewhere in the message with IDREFs. In
the GraphQL logic, there is no concept of reference to an element: as an example,
a service should contain its definition, and not a reference to it, in order to keep
the flexibility of fetching exactly the data needed. The GraphQL way would be to
keep the schema closer to the data model than to the XSDs (and their technical
peculiarities).

37
3.4.2 NDC roles and GraphQL
How to design an NDC GraphQL API depends on the role of the implementer:
different back-end systems are available, and the assumptions and requirements
about the request functionalities or the response content differ. The roles are those
represented in Fig. 2. There are 3 scenarios, as described in the table 8.

Scenario Airline ←→ Aggregator Aggregator ←→ Travel Agent

1 RPC GraphQL
2 GraphQL RPC
3 GraphQL GraphQL

Table 8: GraphQL implementation scenarios

(RPC denotes current message-based NDC)

In scenario 1, the GraphQL API is only supported by the aggregator for the
travel agent. The back-end is necessarily made of RPC calls to the airlines. This
means the aggregator has to construct the XML RQ based on the travel agent
request (which has to have all the necessary information), and has to translate the
XML RS into a GraphQL JSON response, while respecting the response structure
requested by its client.
In scenario 2, GraphQL is implemented on the airline side. The back-end is
either connected to the same systems a regular RPC API uses, or relies on the RPC
NDC API of the airline. Because the aggregator receives full-fledged XML messages,
the airline’s GraphQL API must support all NDC functionalities, or has to inform
the aggregator (which can, in turn, inform the travel agent) of all available services.
In scenario 3, both the airline and the aggregator provide a GraphQL API. This is
similar to scenario 2 for the airline, but the aggregator role is more complex because
it cannot rely on a full-featured API for its back-end. Even if both GraphQL APIs
are completely aligned, the aggregator may have to both aggregate responses from
different airlines and edit the resulting response, for instance in order to comply
with a filter such as a maximum number of offers.
Aggregators cannot modify the content of the messages, according to the Imple-
mentation Guide. They can act as proxies, translate messages from one version of
NDC to another, but they cannot choose which airlines offers to pass on to the travel
agents, unless explicitly agreed with them. After the shopping phase, they only act
as a pass-through. With GraphQL, they have a more active role technically, but not
functionally.
There can be several ways to build an NDC GraphQL API, hereunder divided in 2
categories: starting "from scratch" with the help of the data model, or transitioning
from the current RPC messages.

38
3.4.3 GraphQL driven by the AIDM
The first approach is to use the data model as the foundation of the GraphQL
API. Concretely, the method is analogous to that used today for XSD generation:
from I3, a T3 model is created specifically for GraphQL. Thanks to the similarity
between SDL and the data model, this step does not require any major adjustment.
Compared to the XSD generation, there is no RQ and RS; the RQ is the argument
of the root query (e.g. AirShopping), whilst the RS is the response, both in the
same SDL schema.
The addition of sub-queries arguments (i.e. parameters in the requested response
structure, such as a number of items to retrieve) is not as straightforward. Firstly,
such arguments are inexistent in the current AIDM. Secondly, they may not apply in
every context: some may not be relevant for certain queries, so if they are modeled
in I3, restrictions should be used to remove them in the corresponding T3 models.
Thirdly, because of the ambiguous nature of elements in the GraphQL data model,
as they also are sub-queries, it is not clear how to differentiate in the AIDM the
queries arguments from the elements’ structure. Custom scripts would most likely
be needed in order to generate (with the help of this differentation information) the
GraphQL schemas.
This approach is most suitable for the standardization of a GraphQL flavour
of NDC, especially for airlines implementations since, in such cases, the server has
direct access to back-end databases, services and systems, such as the offer manage-
ment system (OMS) and the passenger services system (PSS).

3.4.4 GraphQL as an evolution of message-based RPC

Another approach, guaranteeing a better consistency with RPC NDC, is to base the
GraphQL queries and mutations on current XML messages.
As stated above, SDL is less feature-rich than XSD, thus less constraining. For
a request, that is problematic: the GraphQL API definition cannot constrain the
user well enough to make their request translatable to a valid RQ. A first solution
is to use the full NDC RQ, but this is more cumbersome for the client. A second
solution is to reduce the number of functionalities by choosing the use cases to be
implemented. In this case, as long as the necessary elements are unambiguously
provided, there is no imperative need to keep the structure of the RQ. An example
of a more granular query is an AirShopping request with origin, destination, date
and number of passengers (adults and children).
A theoretical first step to build a GraphQL API is to encapsulate the classical
RPC exchange: the RQ (XML or JSON) is the only argument of a mutation (to
mimic the POST method), and the response is made of a single String containing
the RS. Of course, there is no added value with this design, but it is the starting
point for the enhancements described below.
The response can be modeled in SDL, so that the users can select what they
need. At first, only the elements used in some use cases can be modeled, then all
the mandatory (as per the XSD) ones, and finally, gradually, the rest. At any of
these stages, sub-queries arguments (i.e. options at the elements/non-root level) can

39
be added in order to provide a more fine-grained selection capability. Such options
could be a number of elements, a maximum price, etc.
Regarding IDs and references, there are two options: keeping them as is, or
moderately restructuring the response. The GraphQL response structure remains
similar to XML messages’ structure with the first option, and this has the benefit of
limiting the size of the response by reducing the amount of duplication. However,
this option is not adapted to the GraphQL way of selecting the response structure
and extent, unlike the second option. Indeed, all elements could be included instead
of referenced, and IDs left in place, since this has no functional impact.
The queries and mutations can be simplified for specific use cases: basic shopping,
listing of services, creation of orders, cancellation of them, etc. Then, the full RQ
can be modeled (and necessarily simplified) in SDL; an API reaching this step is
more error-prone because of the lack of constraints on the request, but this can be
acceptable because (more or less) explicit errors can be returned. However, external
documentation (potentially current XSDs) is needed in order to describe thoroughly
the API.
This approach is particularly fit for NDC APIs relying on back-end RPC calls.
This is typically scenario 1, or any scenario in which a GraphQL API provider relies
on its own RPC APIs as a back-end.

3.4.5 Prototype
The aims of this prototype are to demonstrate the adaptability of GraphQL to NDC,
as an evolution from the RPC messages, and to illustrate the kind of user experience
such an API can provide.

Figure 11: GraphQL prototype as a transformation layer

Building a GraphQL API from scratch on the airline side is out of scope here,
since the complexity it entails (because of the back-end systems that would need to

40
be simulated) does not improve the demonstration of what GraphQL for NDC can
be. Besides, GraphQL as a way to access a database is simple to design and imple-
ment, and several examples are publicly available (e.g. on the official GraphQL web-
site). Tools such as https://github.com/rexxars/sql-to-graphql can generate
a GraphQL server (including its schema and resolvers) based on a SQL database.
This prototype is intended to be a transformation layer the airline puts in front
of its regular RPC NDC API, as illustrated in Fig. 11. This is the simplest way
to provide GraphQL functionalities with an already existing RPC API, without the
need to replicate the complex back-end system.

Because the response is in JSON, and because JavaScript is one of the popu-
lar programming languages for GraphQL implementations, this prototype is pro-
grammed in this language (Node.js with express and express-graphql), and relies on
the JSON version of the IATA NDC sandbox36 . Of course, using an XML API in
the back-end is perfectly feasible too, either by parsing the response message and
working on the corresponding object, or with XQuery, for instance.
The basic implementation principle (illustrated in Fig. 12) is that a new object,
corresponding to the process the client is calling, is created upon reception of the
request. The constructor of this object crafts the relevant JSON RQ message, sends
it to the JSON sandbox, and stores the RS which can then be used by the resolvers
of the response elements requested by the client.

Figure 12: Implementation principle

The prototype has a single endpoint (for GET or POST), and also has an in-
teractive online GraphQL IDE37 : GraphiQL38 . It provides introspection and code
completion; the interface is separated in 3 areas: request, variables, response.

36
which is a JSON-XML-JSON transformation layer on top of the regular XML sandbox
37
integrated development environment
38
https://github.com/graphql/graphiql

41
 The initial scope is the bare minimum to book a flight with NDC: AirShop-
pingRQ/RS, OrderCreateRQ and OrderViewRS. The processes are simplified, but
remain consistent with NDC, which is why they can be translated into XML mes-
sages.
The shopping request is simple:

• origin and destination (airport codes);

• departure date;

• list of anonymous passengers, adults or children, one ID each.

The response keeps the Offer, OfferItem and Service structure, but is simplified:
only necessary elements are kept, containers are removed, and some elements are
reduced to their core meaning (e.g. the price is only the total amount, services are
only described by their name, etc.). No DataList is used in order to be closer to the
ideal of GraphQL. However, IDs are kept wherever they are required for internal
(e.g. a service referring to a flight segment) or external reference (e.g. OfferID).

The order creation is simplified too, in line with the shopping step. All that is
required is the set of IDs (ResponseID, OfferID, OfferItemID), and basic passenger
details. The response only contains the newly created OrderID.

Thanks to the modularity of GraphQL, it is possible to extend this prototype

(if needed, without breaking backwards compatibility), either with the addition of
new elements, or with new request options, such as a maximum price, a maximum
number of offers, the presence of a specific service, etc.
This prototype shows that adapting specialized NDC processes to GraphQL is
relatively simple once the general framework is in place. Because of its simplicity,
the appeal of being able to shape the response is not as great as we could have
expected. This is due to the fact most elements are necessary for the fulfillment of
the shopping and booking tasks. However, the expandability of the API means it can
grow into a more complete solution, for which GraphQL becomes more beneficial.
A screenshot of the GraphiQL IDE with a booking request is provided in appendix.

Below are the structure of the query and mutation available in the first version
of the GraphQL prototype.
Structure of the shopping query
DepartureAirportCode
DepartureDate
ArrivalAirportCode
Passenger
PTC39

39
Passenger Type Code; here ADT (adult) or CHD (child)

42
Struture of the shoppping response
ResponseID
Offer
OfferID
Owner
[OfferItem]
OfferItemID
Price
[FlightService]
ServiceID
[PassengerRef] (ref to PassengerID from request)
[FlightSegment]
SegmentKey
DepartureAirportCode
DepartureDate
DepartureTime
ArrivalAirportCode
ArrivalDate
ArrivalTime
AirlineID (marketing carrier)
FlightNumber (marketing carrier)
[Service]
ServiceID
[PassengerRef] (ref to PassengerID from request)
[SegmentRef] (reference to SegmentKey)
Name

Structure of the booking mutation

OfferID (reference to shopping response)
Owner
ResponseID (reference to shopping response)
[OfferItem]
OfferItemID (reference to shopping response)
[Passenger]
PassengerID
PTC
GivenName
Surname
EmailAddressValue

Structure of the booking response

OrderID

43
Conclusion
Distribution in the airline industry is complex, and so is NDC, notably because of
the variety of processes it has to support.
Thanks to XML and its schema language, XSD, NDC messages are unambigu-
ously defined, thus making a standard. However, since XML is merely a data format,
others can be used to transport the information of NDC messages: with the defi-
nition of a bijection between XML and JSON, the latter can also be used, with no
functional difference. While there is no clear performance advantage in using JSON
instead of XML, it can be more convenient for JavaScript environments.
Regarding the architecture of NDC APIs, while REST is an appealing concept,
the RPC approach is much more suitable in order to guarantee the integrity of
business logic: CRUD operations on resources, in general, cannot enforce it like
processes can.
Finally, the very recent GraphQL API framework is interesting for NDC. Thanks
to its RPC style, and especially for more specialized operations, it can be particularly
useful for clients who wish to fetch exactly the data they need, reducing the workload
and complexity on their side.
As all standards evolve over time, NDC will mature, and may embrace new
formats and paradigms formally. Even if a truly RESTful API does not seem pos-
sible for NDC as it is today, it may be the driving architecture concept for future
standards.

44
References
[1] Subbu Allamaraju. Restful web services cookbook: solutions for improving
scalability and simplicity. O’Reilly Media, Inc., 2010.

[2] Graphcool & community. The fullstack tutorial for GraphQL. https://www.
howtographql.com/. Accessed: July 2018.

[3] Facebook. Graphql, a query language for your api. https://graphql.org/.

Accessed: July 2018.

[4] Roy T Fielding and Richard N Taylor. Architectural styles and the design of
network-based software architectures, chapter 5 Representational State Transfer
(REST). University of California, Irvine Doctoral dissertation, 2000.

[5] Henry H Harteveldt. The Future of Airline Distribution. 2016.

[6] Olaf Hartig and Jorge Pérez. An initial analysis of facebook’s graphql language.
In AMW 2017 11th Alberto Mendelzon International Workshop on Foundations
of Data Management and the Web, Montevideo, Uruguay, June 7-9, 2017.,
volume 1912. Juan Reutter, Divesh Srivastava, 2017.

[7] IETF. RFC 7230. https://tools.ietf.org/html/rfc7230. June 2014.

[8] IETF. RFC 7540. https://tools.ietf.org/html/rfc7540. May 2015.

[9] IETF. RFC 8259. https://tools.ietf.org/html/rfc8259. December 2017.

[10] Meteor Development Group Inc. GraphQL vs REST. https://dev-blog.

apollodata.com/graphql-vs-rest-5d425123e34b. Accessed: August 2018.

[11] Ecma International. Ecma-404. http://www.ecma-international.org/

publications/files/ECMA-ST/ECMA-404.pdf. Accessed: June 2018.

[12] Falco Nogatz and Thom Frühwirth. From xml schema to json schema-
comparison and translation with constraint handling rules. Bachelor Thesis.
Ulm: University of Ulm, 2013.

[13] JSON Schema Organization. JSON schema. http://json-schema.org/. Ac-

cessed: June 2018.

[14] Alex Rodriguez. RESTful web services: The basics. IBM developerWorks,
2015.

[15] SmartBear Software. SOAP vs REST APIs: Which Is Right For You?
https://www.soapui.org/learn/api/soap-vs-rest-api.html. Accessed:
June 2018.

[16] W3C. XML technology. https://www.w3.org/standards/xml/. Accessed:

May 2018.

45
Appendix
Example of AirShoppingRQ in XML and JSON

Example of AirShoppingRQ.xml
1 <AirShoppingRQ Version="IATA2017.2"
2 xmlns="http://www.iata.org/IATA/EDIST/2017.2">
3 <Document>
4 <Name>Kronos NDC GATEWAY</Name>
5 <ReferenceVersion>1.0</ReferenceVersion>
6 </Document>
7 <Party>
8 <Sender>
9 <TravelAgencySender>
10 <Name>JR TECHNOLOGIES</Name>
11 <IATA_Number>20200154</IATA_Number>
12 <AgencyID>00010080</AgencyID>
13 </TravelAgencySender>
14 </Sender>
15 </Party>
16 <CoreQuery>
17 <OriginDestinations>
18 <OriginDestination>
19 <Departure>
20 <AirportCode>AUH</AirportCode>
21 <Date>2018−09−26</Date>
22 </Departure>
23 <Arrival>
24 <AirportCode>TLS</AirportCode>
25 </Arrival>
26 </OriginDestination>
27 </OriginDestinations>
28 </CoreQuery>
29 <DataLists>
30 <PassengerList>
31 <Passenger PassengerID="SH1">
32 <PTC>ADT</PTC>
33 </Passenger>
34 </PassengerList>
35 </DataLists>
36 </AirShoppingRQ>

Example of AirShoppingRQ.json
1 {
2 "AirShoppingRQ": {
3 "$": {
4 "xmlns": "http://www.iata.org/IATA/EDIST/2017.2",
5 "Version": "IATA2017.2"
6 },
7 "Document": {
8 "Name": {
9 "_": "Kronos NDC GATEWAY"
10 },
11 "ReferenceVersion": {

46
12 "_": "1.0"
13 }
14 },
15 "Party": {
16 "Sender": {
17 "TravelAgencySender": {
18 "Name": {
19 "_": "JR TECHNOLOGIES"
20 },
21 "IATA_Number": {
22 "_": "20200154"
23 },
24 "AgencyID": {
25 "_": "00010080"
26 }
27 }
28 }
29 },
30 "CoreQuery": {
31 "OriginDestinations": {
32 "OriginDestination": [
33 {
34 "Departure": {
35 "AirportCode": {
36 "_": "AUH"
37 },
38 "Date": {
39 "_": "2018−09−26"
40 }
41 },
42 "Arrival": {
43 "AirportCode": {
44 "_": "TLS"
45 }
46 }
47 }
48 ]
49 }
50 },
51 "DataLists": {
52 "PassengerList": {
53 "Passenger": [
54 {
55 "$": {
56 "PassengerID": "SH1"
57 },
58 "PTC": {
59 "_": "ADT"
60 }
61 }
62 ]
63 }
64 }
65 }
66 }

47
AIDM I3 model of Passenger (18.1)

48
Extract of AIDM T3 model of AirShoppingRQ (18.1)

49
Extract of AirShoppingRQ.xsd (17.2) – Altova XMLSpy "schema"
view

50
Prototype: GraphiQL IDE with a booking request

51