A first approach

Looking for an appropriate and self-explaining name for a data exchange format for accommodation I ended up with "accommodation exchange format" and from there with a shortened version "AccoXchange?" which is what I use as name for the root element.

The first decision I had to take was if I wanted to have data of just one hotel per transaction (or file, depending on how data is transferred). I decided to allow any number of hotels in the format specification. This bears the risk that someone would try to put the complete ARI and static data of, say, twenty thousand hotels into one single transaction.

Taking into account that HTTP(S) POST will be the preferred way of data transfer there are of course some limitations when it comes to size. However, the service would not need to wait until all the data has been processed in order to return with a HTTP status code. As soon as all the data has arrived it will return a 202 Accepted. The actual processing will take place after the response was returned.

This means that the time required for receiving the data (without all the processing) is the only limiting factor. With a timeout of 60 seconds the amount of (deflated/compressed) data that can be transferred is considerable. But there are still two factors which make it impossible to predict how many contracts may be sent in one single transaction.

  • The size of each contract may vary between 70 Kbytes and 70 Mbytes.
  • The transaction speed varies depending on factors ranging from traffic load on the system to bandwidth and quality of physical connections.

In my opinion it does not make sense to hard-wire a limit of the number of contracts/hotels for a data format. This number must be configurable for each receiving system. And of course, there must be a way for the sender to query these settings so it can adjust the number of contracts/hotels to the setting.

As the AccoXchange? format is meant to be used for both sending complete as well as incremental hotel data it makes much sense to send all incremental updates in one single request. If incremental updates are sent every five or ten minutes the transaction size will be very limited anyway.

In order to initially populate a system with new contracts you might want to send only data for one hotel in one transaction - the option is there. But if you want to send contract data in chunks of 10 or 100 or any other safe number of hotel contracts, it is up to the sender as long as he respects the threshold set by the receiver.

Hotel or contract?

There is quite a lot of confusion when it comes to the terms hotel, and contract. When working with a new supplier it is quite frequent that the meaning of IDs must be clarified. Some might refer to the hotel as the company you have a contract with, others might refer to the actual contract and others again only to the physical building. Sometime transfer formats try to add some distinction by avoiding "Hotel" as an element name. In AccoXchange? <Hotel /> is used to transport information for one hotel contract. If there are two or more contracts for the same hotel, the static data for this hotel will be duplicated. This adds redundancy but also makes the whole structure more flexible and most importantly more explicit.

Whose data is it?

When you receive data you will certainly want to know where the data comes from. This information is transported in the "Supplier" attribute of the AccoXchange? root element. This is almost the only mandatory information.

Access control

Formats such as OTA and HTNG have user and password attributes in their data format. I think that access control must not be part of the format because they are not effective as a security measure and there are more appropriate access control mechanisms ranging from firewalls to HTTP BasicAuth?.

So, the starting point for the AccoXchange? format looks like this:

<?xml version="1.0" encoding="UTF-8"?>
            <AccoXchange Supplier="ABC">
Last modified 19 months ago Last modified on Sep 14, 2017 7:08:55 PM