by Peter B Wright
UK Trail
Email: forums AT uktrail.com
(You are welcome to copy or quote from this article, with acknowledgement.)
1. Standard Format — the concept
1.1. In the environment of computer systems, there is frequently a need to exchange data. For example, databases and spreadsheets very often need to exchange data.
A set of software packages developed together (such as MS Access and MS Excel) have their own methods of exchanging or sharing data, and it doesn't matter to anyone else what these are. But if they want to exchange data with another package, both they and the other package must be able to write and read the same format.
1.2. Such a format needs to be in an easily-specified layout that works for any kind of data, and the format must be something non- proprietory such as a text file, rather than, for example, a MS-word DOC file which has many embedded codes which may change with new releases.
1.3. The most accepted layout for data exchange is Comma-separated. A comma-separated file comprises:
Any number of lines of data.
Each line comprises any number of data each separated by a comma.
Numbers are represented as such, and text items are represented inside double quotes.
The first line (optional) can be a list of text items which describe the data.
Here is an example:
"Year", "Month","Date","Reference", "Temperature","Rainfall","Fog"
2009,3,14,"HD345",12.2,0,"Yes"
2009,3,15,"HD348",12,16.1,"No"
2009,3,16,"ZY19",10.8,0,"No"
A different separator can be used (eg a semicolon or a space) instead of a comma as long as both partners recognise it.
1.4. Limitations of comma-separated.
a) It works well only when the same variables are transferred every time. For example, a spreadsheet could be programmed to receive files such as the above and calculate the average temperature. It would be very confusing if the author decided to insert a column "sunshine" before that for "temperature".
b) Every item has its place in the order and must be included every time; if an author does not supply it, it still has to be included (as a blank item) in the file.
1.5. Another standard layout.
A newer standard layout is XML. This does not have the above limitations. It is more complex and therefore needs more programming, but this only needs to be done once by a given software system. XML is described more fully below.
2. What data exchanges do hostels have to make?
2.1. There are two labour-intensive processes involving exchange of data which have to be performed very frequently (at least once a day for many hostels). These are:
a) Receiving details of bookings from booking engines, and updating the hostel's bednight allocations.
b) Sending details of current vacancies to each of several booking engines.
2.2. Some hostels keep their bednight information in manual form. Such hostels have a low frequency of transactions, and it is not onerous for them to use manual methods also to update their bookings and vacancies. But most hostels have their bednight information on computer, either in a spreadsheet or in a proprietory software system. In these cases, it would make the utmost sense to be able to transfer it to and from booking engines in computer form rather than go through a manual stage.
Currently, this is rarely possible. Bookings are received by hostels in text format, and have to be manually typed into their computer system. Then, the hostels list their vacancies in their system, then have to log in to the booking engines, one by one, and type in the changes manually.
There are some bednight software systems, written by a booking engine, that communicate with that booking engine in an internal way, because they have been written as a unit. Hostels with these software systems can automatically update that one booking engine, but to update other booking engines is just as tedious as before.
It would make sense if the hostel could: Create a file containing all their bed vacancies; Log in to a booking engine; click on a button which sends that file from their computer to the booking engine. The booking engine would have programmed their system to accept that file and automatically update the vacancies. If all booking engines accept the same format, then the hostel needs to create only one export file.
3. What solutions are possible to the data exchange problem?
3.1. The crucial need is for the hostel front desk software to generate their vacancies in a standard format that the booking engines are programmed to read. Similarly in reverse for bookings received by the booking engine.
3.2. A standard format should be devised. Writers of software for hostels would program their systems to output information on vacancies in this format, and to import booking information in the same standard format. Booking engines would enable their systems to import a file of vacancies in this format, and to export their booking details as a file in this
standard format.
3.3. First option: Text Format. Booking engines currently issue the details of their booking in text format. If this format were suitably laid out, a program could be written to separate out the essential information and input it into the hostel's software. But this would be different for each booking engine, and if the booking engine changed the layout, the program would have to be re-written. And in the example we have seen, the text information is very nsuitably laid out.
3.4. Second option: Comma-separated format. This would be much easier, but there would still be the limitations mentioned in 1.4.
3.5. Third option: XML files.
This would involve more programming initially, but most computing languages can do this, and the result would allow much greater flexibility, given that different clients need to offer or extract different combinations of data.
4. What are XML files?
XML files are files of data expressed in a particular flexible layout (see examples in 5.). Different users can send different data items. As long as the names of the fields are standardised, everybody can cope with the same files, and there's no need for a program to be re-written if the issuer changes the items included (as long as the items essential to the receiver, such as the number of guests, are always included).
We will propose a set of code-names, eg "Dorm size=6" would be the code for 'number of vacant beds in 6-bed dorms', "Priv size=3" for 'nr of vacant beds in 3-bed privates', etc. If a hostel works only with dorm beds without specifying sizes, it will use the code-name "Dorm".
Every software writer, and every booking engine, could write a program module in their chosen language to receive and produce XML files. Most programming languages have routines to make this easy. If a hostel uses, say, a spreadsheet which does not have this facility, then their system can generate and receive comma-separated files, and an interface
program could be written, for example in Java or PHP, to translate between the two types of file. All this programming would need doing only once.
I will be pleased to help, on a non-commercial basis, with the development of a suitable set of codes for XML files to be used to transfer data between hostels and booking engines.
5. Example XML files.
a). Example XML file to be sent by hostel to booking engine. This is for a hostel which specifies dorm sizes, has private rooms, and gender not important. In this example, the booking engine entry for this hostel will be already set up with boxes for "6-bed dorm", "3-bed private" etc.
<Vacancies Hostel="Tyncornel Hostel" Ref="12345">
<Date date="20/08/08">
<Dorm size="6">2</Dorm>
<Dorm size="4">8</Dorm>
<Priv size="3">3</Priv>
<Priv size="2">6</Priv>
</Date>
<Date date="21/08/08">
<Dorm size="6">15</Dorm>
<Priv size="2">6</Priv>
</Date>
....
</Vacancies>
b). Example for a hostel with single-gender dorms, size not important. In this example, the booking engine entry for this hostel will be already set up with boxes for "Male dorm" and "Female dorm". The lack of an entry for Female Dorm on 21st implies that there are no vacancies for females.
<Vacancies Hostel="Tyncornel Hostel" Ref="12345">
<Date date="20/08/08">
<Dorm Gender="Male">8</Dorm>
<Dorm Gender="Female">6</Dorm>
</Date>
<Date date="21/08/08">
<Dorm Gender="Male">5</Dorm>
</Date>
....
</Vacancies>
c). Example XML file to be sent by booking engine to hostel concerning a single booking. In this example, if the hostel is not concerned about the gender of each guest, it simply ignores those lines.
<Booking Source="Hostelbookers" Hostel="Dolgoch Hostel" Ref="13456">
<BookingRef>"13579-111222"</BookingRef>
<Name>"Smith"</Name>
<First>"John"</First>
<NrGuests>"2"</NrGuests>
<NrMale>"1"</NrMale>
<NrFemale>"1"</NrFemale>
<FirstNight>"13/08/09"</FirstNight>
<NrNights>"3"</NrNights>
<TotalCost>"90.00"</TotalCost>
<AgentFee>"9.00"</AgentFee>
<AmountPaid>"9.00"</AmountPaid>
<Balance>"81.00"</Balance>
</Booking>
