Executive summary: The airline standards landscape looks like acronym soup (NDC, ONE Order, AIDM, Open Air, EASD, Modern Airline Retailing), but it has a single organizing idea: one governed canonical model (AIDM), from which the XML and JSON standards are generated as projections. Once you see that structure, three practical things change: how you plan integrations across the NDC versions your partners actually run, how you think about validation, and how you make your own data consumable by AI agents. The same architecture that IATA uses to govern an industry is the architecture your integration layer needs internally.
If you run IT at an airline, an OTA, or a travel-tech vendor, your integration budget already knows the problem this article explains. Your partners are simultaneously on NDC 17.2, 18.2, 21.3, and 24.x, and 21.3, not the newest release, is still the most widely deployed version in production. Every partner and every version pair spawns another mapping, another test matrix, another source of production surprises. The standards map is how you stop treating that as fate.
The map in one paragraph
AIDM (Airline Industry Data Model) is IATA's canonical data model at the center. NDC (XML) and Open Air (JSON/REST) are serializations derived from it. ONE Order is the fulfilment-and-servicing counterpart to NDC's shopping side. The umbrella program is Modern Airline Retailing, the "100% Offers and Orders" vision, delivered through the EASD (Enhanced and Simplified Distribution) standards family: NDC plus ONE Order plus settlement with orders.
A few load-bearing facts behind the boxes:
- NDC launched as IATA Resolution 787 ("Enhanced Airline Distribution") at the Passenger Services Conference in Abu Dhabi, October 2012, and won conditional US DOT approval in 2014. It is built around Offer and Order concepts: rich content, branded fares, ancillaries, and real-time pricing to any channel, everything the legacy EDIFACT messaging could not express.
- ONE Order (Resolution 797, now branded "Fulfilment with Orders") collapses the PNR, the e-ticket, and the EMD into a single order record. The clean split to remember: NDC is how the airline shows you an offer and takes your order; ONE Order is the single living record of what you bought and how it gets delivered and settled. Neither replaces the other; they are two halves of one transformation. Why the industry needed that unification is a story of its own, and we tell it in why airline IT looks the way it does.
- AIDM is maintained as a UML information model (in a Sparx Enterprise Architect repository) under IATA's Architecture and Technology Strategy Board, and Resolution 009 mandates that new data-exchange standards follow AIDM methodology, so schemas are generated from the model rather than drafted independently. That mandate is the lesson of NDC's messy early years: letting each standard define its own data in isolation produces fragmentation and endless mapping.
- Open Air is the REST/JSON lineage: OpenAPI 3.0 specifications sourced directly from the AIDM logical model (Flight Status is a good public example). It is the answer to "why does IATA publish both XML and JSON": one canonical model, two projections.
- Adoption reality check: roughly 75 airlines are on IATA's Airline Retailing Maturity index, industry surveys put the share of airlines that have genuinely started Offer-and-Order transformation at about 27%, and analysts expect mainstream adoption only toward the end of the decade. Translation for planners: you will run old and new in parallel for years, and the harmonization layer is not a transition cost; it is the product.
The three-layer framework: model, schema, instance
The map becomes usable once you separate three layers that teams habitually blur:
- Layer 1, Model (AIDM): conceptual truth. Written once, human-facing, serialization-free. Defines that a Price has an Amount and a Currency, and what those mean.
- Layer 2, Schema (XSD or JSON Schema): the machine-checkable rulebook. Written once; judges other documents. Allowed values, choices, patterns, and cardinalities live here, not in the data.
- Layer 3, Instance: one actual payload. Written millions of times. Validation is checking a layer-3 instance against a layer-2 schema.
The corollary most people miss: XSD and JSON Schema are themselves projections of AIDM's constraints, the "one model, two projections" story repeated one level up, on the rules instead of the data. In one line: the canonical model governs semantics; the schemas are its enforceable projections; the instances are traffic.
The one-second proof: the Price object
Here is the entire architecture in three snippets. In AIDM's logical model (no serialization):
Price (ABIE)
├─ Amount : Decimal [1..1]
└─ CurrencyCode : Code [1..1] → Currency codesetThe NDC-style XML binding puts the amount in the text node and the currency in an attribute:
<Price><Amount Code="USD">245.50</Amount></Price>The Open Air-style JSON binding uses two sibling keys, because JSON has no attribute concept:
{ "amount": 245.50, "currencyCode": "USD" }Both carry exactly the same two facts: 245.50 and USD. Every visible difference (attribute versus element, key naming, ordering, namespaces) belongs to the binding layer, not the model. Serialization is a binding choice, never a meaning choice. When your teams internalize that, cross-format mapping stops being interpretive work and becomes mechanical work, which is exactly what makes it automatable.
The working vocabulary: XSD and JSON Schema, side by side
For teams that live in both worlds, the pairings worth memorizing:
| Concept | XSD | JSON Schema |
|---|---|---|
| Cardinality | minOccurs / maxOccurs | required array + minItems |
| Code set | xs:enumeration | enum |
| Shape rule | xs:pattern (e.g. [A-Z]{3}) | pattern |
| Exactly-one choice | xs:choice | oneOf |
| Reuse | named type + type= | $defs + $ref |
| Inheritance | xs:extension / xs:restriction | allOf (approximates it) |
| Open or closed by default | closed | open, needs additionalProperties: false |
And the practical gotchas that bite aviation payloads specifically: JSON has no native date type (a departure time is a string plus a format hint); 189.00 equals 189 in JSON, which is why careful finance APIs carry money as strings; JSON objects are unordered, so there is no xs:sequence equivalent; and OpenAPI 3.0 uses an older JSON Schema dialect than the current 2020-12 standard, which matters when you generate validators.
The AI-readiness angle: closed contracts and determinism
That last table row is the quiet headline. XSD is closed by default; JSON Schema is open by default. A schema that does not declare additionalProperties: false lets any partner smuggle undeclared fields into production payloads, and lets an AI agent hallucinate plausible-looking ones.
This matters now because AI agents made the JSON projection strategically important: MCP (Model Context Protocol), function calling, and effectively every agent framework speak JSON natively. When an autonomous agent shops your inventory, there is no human in the loop to shrug at an ambiguous field. Agent-consumable interfaces need deterministic, closed contracts: explicit types, enumerated values, closed schemas, and documented meanings. The airline industry's newest consumers, shopping agents, are the strictest schema critics the industry has ever had. (Why access alone is not enough, and why agents also need governed business definitions, is a topic we covered in why AI agents still get business questions wrong.)
XML is not going anywhere either: XSD offers deeper structural validation, XML digital signatures support signed, non-repudiable B2B flows, and a decades-deep install base speaks it. An industry this size keeps both projections, which is precisely why the canonical model in the middle is non-negotiable.
Treat your own integration layer the way IATA treats AIDM
Here is the transferable lesson, and it has nothing to do with waiting for IATA. Inside your own estate, you face a miniature version of the same problem: multiple NDC versions, partner-specific dialects, aggregator APIs, legacy internal formats. The failure mode is bilateral mappings: every source mapped directly to every consumer, an N×M matrix where every new partner multiplies work.
The AIDM pattern applied internally:
- Define meaning once in a canonical model of your offers, orders, customers, and services, including the definitions your teams argue about.
- Normalize inbound traffic to canonical, with one mapping per partner into the model, not one per partner-consumer pair.
- Generate outbound projections per partner, per version, per format, as mechanical bindings from the canonical layer, ideally generated rather than hand-written.
- Validate at the boundary with closed schemas, so agents and partners get deterministic contracts.
That turns N×M into N+M, converts version upgrades from projects into configuration, and gives you exactly one place to make data AI-ready instead of dozens. It is also the architecture behind how the economics of agentic shopping get solved, as we explain in our analysis of AI agents and airline distribution economics.
Takeaway: a one-question maturity check
Ask your architecture team one question: do we have a canonical layer, or do we have N×M mappings wearing a trench coat?
Honest signs of the second: adding a partner means writing mappings to more than one internal consumer; the same business concept has different names in different pipelines; version upgrades are scheduled as projects; and nobody can produce the list of allowed values for a field without reading code.
If the answer is the trench coat, that is fixable, and fixing it is upstream of everything else on the modern-retailing roadmap. Our travel and tourism data practice helps airlines, OTAs, and travel-tech vendors build the canonical layer and the standards integrations on top of it, from blueprint to build.
