Basics

Why XFT

Online transactions to sell travel related packages were proposed by Galileo France as early as 1998, to complement the Open Link Platform. At that time though, the travel actors were not prepared really to be compared because, the initial steps before online selling is the shopping, when a user searches the internet, gets result lists and compares them before actually selecting certain products for more precise quotations and possibly a booking finalisation (with or without payment).

Over the years, mentality and needs have evolved so that the same actors finally decided to develop online transactions through a travel oriented language. At that time, the OTA transactions have been investigated but they were not fulfilling a number of the requirements, such as the capacity for quick evolution, the importance of flexibility, the capacity to work for very different types of selling processes as widely different as Kuoni or Jet Tours and Marmara or Thalasso Number One selling processes, the coherence of objects in different transactions. The OTA transactions in 2002 / 2003 were very limited in terms of reselling pre packaged tours (this being not very widely spread in the States and the initial OTA transactions being first centred on profile management and not selling processes). They are also very strict and required many evolutions. The vendors were also having some difficulties depending on an American body for their core business, having always refused to become dependent on the GDSs.

As a consequence, there was a need to develop a travel oriented language. The tour operators could have decided to start from the CETO XML format, dedicated to travel catalogue exports. However, transactions means exchanges between different types of actors: the vendors that provide the products to be sold, the service companies and GDSs (Amadeus, Galileo/Wordspan, Sabre) that develop online selling platforms, distributors that ultimately sell the products (traditional and web agencies). To ensure the success of the language and adhesion of the whole chain of actors, the tour operators decided from the very beginning to involve all the types of actors.

The XFT language (eXchange For Travel) has thus been created in 2003.

What is XFT ?

The XFT Language initial objectives were to allow direct access to vendors once a pre-packaged tour is selected from a list issued from a package engine. Search transactions were not really required at that stage because there were already existing search engines based on the CETO Catalogue XML formats. Those engines acting as caches, there was no need to have XFT search transactions at that stage.

Once a package is selected, there is a need first to access the vendor with precise request parameters to obtain a quoted availability transaction for a given product (returning at the same time a quote and availability status and providing capacity for cross and up selling).

The second transaction was a booking creation transaction (request, option or confirmed) returning a valid reference number from the vendor

A number of simple booking management transactions were also introduced, like a complete booking cancellation, an option confirmation or abortion, a booking retrieval and finally a cancellation fee request.

However, from the beginning, the XFT was not just a mere collection of transactions, but was structured as a language, with a grammar, vocabularies, verbs and a syntax which is schema validated.

The XFT language is an object oriented language implementing inheritance, pointers recursivity …, based on seven families of entities:

• The types extend standard XML types through regular expressions (upper case, 3 digits upper codes (for IATA codes)), union of free text and codes …, mostly used in the definition of attributes.

• The enumerations list valid values for strict validation (list of meal plan codes, vendor codes …). It is mostly used in the definition of attributes and other types (through XSD unions).

The attribute groups are collection of several attributes grouped for functional reasons used in the definition of classes.

• The elements are instances of a class and constitute the actual XFT vocabulary. An element has a particular usage. They are either directly used in XFT files and transactions or as class constituent.

Some may be synonyms of others and can be substituted to others without the use of inheritance.

• The collections are instances of a collection class, used to contain a collection of elements or collections of the same type.

They are either directly used in the XML files and transactions or as class constituent.

• The group is an abstract element used in schema definitions but never present as true XML entities. It is used either to group elements and collections of the same type such as a room or a collection of rooms (called coherent groups) or to group element of different types but with functional proximity, such as a trip begin and end, a trip departure and arrival location (called aggregates). The use of groups increases the readability of schema but imposes the order of tags.

• The class is the equivalent of a class in Object oriented programming. It corresponds to a complex type in schema. Classes constitute the XFT back bone.

A complex type may contain attributes, attribute groups, elements (both unique items and collections) or groups.

XFT Classes are seldom independent but rather inherit from more basic classes. For instance an air segment would inherit from a transportation segment that would itself inherit from a segment, derived from a travel entity, itself derived from an entity, ultimately coming from an atom.

To a class correspond at least a collection class, an element, a class element and a group) Specific types and enumerations may also exist as well as inherited classes or aggregates. There are classes for individual items and collections

All elements used in the XFT have a corresponding class, usually inherited from other root classes. A class is never directly present in an XML file or transaction.

The interactions between the different entities are illustrated in the diagram below:

Easy to master naming conventions allow self explanatory interpretation and navigation in the schema. For instance the class for a room is RoomType (Room being the element) and the corresponding collection class is RoomCollectionType (and Rooms for the element). The group is named RoomGroup. RoomType has an attribute named Code defining whether the room is a double, a single … The enumeration used to validate the attribute values would be named RoomCodeCodeType (CodeType being the postfix for all enumerations).

State of the art

Since 2003, The XFT has greatly expanded. The association for instance, that started in 2004 with seven members has now thirty six members, with most majors travel related companies in France.

The quantity and content of the transactions have also much evolved: There are now

• Search engine transactions (for packages, flights, accommodations …),

• Information requests (to have more details on specific items, such as media data, departure dates, availability, price tables …),

• The original online selling transactions (quoted availability, quote, availability, create booking or option)

• Some user management transactions, such as user authentication, user creation, search, management, …

• Booking management transactions:

• Get Booking, Update Booking, Search Booking, Confirm Booking, Cancel Booking, Release Booking