Travel Analytics Blog
XML Versus EDIFACT
Posted by Sonja Woodman on Sunday, May 22, 2016
So far in the previous three articles we have discussed what XML is, what NDC is and why NDC is based on the XML messaging system rather than the pre-internet electronic data interchange system known as EDIFACT. This article addresses some of the key differences between the two to explain why airlines need to embrace XML if they are to succeed in getting more revenue from innovative ancillary sales. What this article doesn’t do is dismiss EDIFACT altogether, recognising that it has robustly served the airline industry (among others) for 40 years while passenger and flight numbers have grown steadfastly. Any change is likely to be evolutionary not revolutionary.
We’ve mentioned that GDSs and their network of airline suppliers began using the electronic data interchange standard EDIFACT for information exchange early on. It is now regarded as legacy technology, but for many years it has been very stable and robust enough to handle the large transaction volumes of hundreds of thousands of travel agents using it every day to book flights and rooms. In fact at this point it is probably worth emphasising the importance the GDSs currently play in the selling of airline tickets to the most lucrative market (e.g. business travellers). According to Amadeus, 15 -20% of airline tickets sold through travel agents are interline (e.g. complex itineraries served by multiple carriers where the money is split). This is critical for an airline to expand reach and where the GDSs excel.
EDIFACT will continue to prove useful in the sale of tickets for some years to come, since the messages are highly structured and quite small in size. Indeed over the years the airline industry has made a huge investment in EDIFACT so XML should not be regarded just in terms of a competitive alternative (although it may become that), but rather complementary – as the airline ‘merchandising revolution’ evolves. So in the context of ancillary sales it brings that extended functionality. Many GDSs have begun to incorporate XML into their technology – and after the bitter NDC debate in the public square, the GDSs are coming round to the view that XML will be good for the industry as a whole.
These days when airlines talk about "merchandising," they are referring to three things:
- Optional services such as bags, speedy boarding, premium seats, meals, etc
- Branded fares, which have commercially recognisable names and specific attributes for differentiation and upselling
- Desire for customer insight in order to achieve greater personalisation of offers
In this context EDIFACT is a constraining technology when it comes to unbundled fare structures while the more flexible XML offers many more opportunities to support the innovation that is needed (and that NDC is designed to promote). In essence, NDC is all about introducing a common, open XML-based standard that gives travel agents easy and transparent access to the same products, ancillaries and information that is available on airline websites.
So how are the two messaging systems different? Essentially the difference is structural and in the treatment of the data itself.
EDIFACT has been great for handling high transaction volumes, but this is down to being created when bandwidth cost was a consideration. EDI messages are compact and minimalist and use codes to represent complex values. Since it is legacy technology, there are fewer people and tools to support it, making it an expensive option to maintain. It has its own proprietary language which lends itself to closed communities and requires developers who can code new requirements. This means that adding new products or services can take time and be costly, as many airlines requesting even small changes from GDSs can testify.
XML, on the other hand is rich in meta data making it larger in size, but easier to read and debug. Although a more verbose language it offers the flexibility to include media rich data such as pictures and videos. There are more people who can work with XML, more tools to support it and it doesn’t require specific coding expertise. In general introducing new features between trading partners is quicker, easier and cheaper using XML. The size of XML messages has in the past made it less attractive for very high volume applications – although the popularity of the internet for conducting travel searches is changing this with popular online travel companies and intermediaries dealing in very high search volumes.
So, while EDIFACT is still a popular syntax to use in high volume bi-lateral connections or within closed communities (e.g. GDSs and the airlines) XML is increasingly preferred for reaching a disparate set of customers using different systems via direct APIs (e.g. online travel websites, wholesalers, hotels, etc.). It is XML's more intuitive format that makes users prefer it over EDIFACT’s more cryptic and simplistic format.
Having said all that, there are hundreds of millions of airline transactions and it is recognised that GDSs still account for approximately 60% of that. Entrenched relations between Travel Management Companies (TMCs) and the GDSs mean that percentage is probably not going to dramatically change any time soon. Adoption of XML among the legacy airlines is still new although the Low Cost Carriers (LCCs) use it extensively, but until recently they have avoided going through the GDSs, although Ryanair and EasyJet’s appetite for business passengers has changed that approach.
Where XML will shine is in the selling of all those ancillary services around airline seats. These at least to begin with, will not be as high volume as airline seats, so it makes sense to use XML for those ancillaries because XML makes it easier to add products or change the offering in line with seasons or market drivers So, if an airline wants to offer certain passengers lounge access or on-board Wi-Fi, or airport parking, etc. It's much easier for the airline and the technology provider to do that with XML. It is quick and inexpensive to make those product innovations and changes.
But it is possible to see situations where XML and EDIFACT may co-exist, with the ancillary related message being shipped back to the agent’s desktop, whether it's a GDS or another provider. Indeed most travel agencies today are not using the typical “green screen”, as Amadeus, Sabre and Travelport, the three major GDSs have all made strides in developing Graphical User Interfaces (GUIs) to increasingly present some of the ancillary options the airlines want to sell. The travel agent is given the option of switching between the two screens as needed. Experienced agents can often perform certain functions, such as intricate itinerary searches, more quickly using cryptic commands.
The GUIs have been designed to look like a green screen. Guiding the mouse over certain items can produce popups containing text or photographs. Some of the GDSs also have direct connects with some of the Low Cost Carriers (LCCs) via XML APIs that allow the GDS access to the airlines’ web-based displays, but each direct interface requires significant resources and can be expensive so not really a solution for connecting with hundreds of airlines. There is also the minor question of who would pay?
NDC is a new beast based on XML. It is needed because Airlines need to be able to become merchandisers, not just people transporters if they are to become more profitable. NDC has been endorsed by the US Department of Transport (DOT) and is getting increasing support from its erstwhile opponents, with Amadeus leading the charge. It remains to be seen how quickly the industry will not only embrace but implement NDC, so in the real world, EDIFACT is likely to co-exist alongside XML in a complementary way within the GDS environment for some time to come.
In the next article we will show Why Online Travel Depends on XML.
As a quick reminder this 2 minute video shows how XML works for airlines.