FAQ

The production and processing of OTDS as the Open Tourist Data Standard is very multifaceted and powerful, but not self-explanatory. The OTDS e.V. offers assistance in the OTDS Forum, where the Technical and Thematic Documentation can be called up, whereby the latter is reserved for members of the Association.

For a quick orientation we have compiled answers to the following, most frequently asked questions. This FAQ collection is continuously being expanded.

Formalities

What are the rules for naming an OTDS file?

An OTDS delivery must fulfil the following properties:

  • Deliveries occur principally as .zip-files.

  • This file can only contain one or more .xml-files. The file extension of the files must be .xml.

  • No subdirectories may be used.

  • All file names (except delivery.xml) must begin with a 3-digit or (if those 3 digits are not sufficient) a 5-digit number. If the number is too small, zeros will be placed at the beginning of the number to bring it up to 3 respectively 5 digits.

  • The row of numbers must be unambiguous.

  • File names can optionally contain additional characters after the 3-digit respectively 5-digit number. These characters can only be selected from the ranges a-z, A-Z, 0-9, - and _.

  • The .zip file must contain a delivery.xml file. This file contains additional information for this delivery.

Structure of the XML files
  • All XML files must contain the correct specification of the font in first line of the file: <?xml version="1.0" encoding="UTF-8"?>
  • All XML files should use the font UTF-8. If this recommendation is deviated from, then the alternative font must be correctly specified in the aforementioned XML declaration in all files.
What is important with regard to the validation of the data delivery?

The delivered data sets must be validated at all times against the original OTDS schema file "otds.xsd ", i.e. there must be a valid data set available at all times.

If several files are delivered within a delivery, each individual file must additionally be validated against the incremental XSD, for which the majority of elements are optional. This XSD (otds.xsd) is to be found in the schema directory in the "incremental_xsds" sub-directory.

Which one is the XSD-"Master"file?

For all activities in the XSD-files start with the file otds.xsd. All other XSD-files are embedded in this file.

FEATURES OF OTDS

What is SellingAccom good for?

 SellingAccom contains the sales-relevant accommodation data, including prices and availability. Here the actual product offer is defined by the combination of certain rooms (unit) and catering (board).

This often involves distribution for different customer groups, such as families, young couples or singles. In addition to the booking parameters, the properties also record the characteristics of the accommodation as well as included additional services.

SellingAccoms correspond quasi to seasons. Practice has proven that a limitation to a maximum of ten SellingAccoms makes sense, because no tour operator really works with more seasons. For bed banks, however, this limitation makes no sense.

Each SellingAccom node requires a unique key value for this node. Usually, the key value contains the booking code of the accommodation and, if necessary, the season indicator or trip type as parameters.

What is SellingUnit good for?
SellingUnit contains all sales-relevant data for the room for sales. In addition to the booking parameters, the availability and properties of the room are also defined. Filters can be used to limit a room to certain conditions (e.g. not between Nov - Feb). All price components (PriceItems) delivered under SellingUnit are only valid for the respective room. Often different occupancy variations matter also, as they result in different prices. Inportant: Each "SellingUnit" node requires a unique key value to be specified.
May I write free text in properties?
Free text can only be used in certain properties:
  • Numerous properties do NOT allow free text. For reasons of standardization, values are selected in these properties from a predefined list.
  • For the name properties the input of free text is required, because these cannot be standardized. Specifically these are the properties AccommodationName (name of the accommodation, e.g. "Berlin Grand Hotel"), UnitName (e.g. "Appartment with balcony"), BoardName (name of the catering service, e.g. "Half Board Plus") as well as AddonName (name of the additional service, e.g. "Diving Excursion")
  • Finally there are still Properties, whose contents must be entered freely, whose form is however given, like for example with AccommodationAddress the sub-elements Street, Mail etc.
Since OTDS 2.0, the integration of Nonbookable content is also possible. This Nonbookable Content was set up for the properties AccommodationInfo, AccommodationCityInfo, UnitInfo, BoardInfo, AddonInfo, AddonServiceInfo, AddonServiceFeatureInfo and allows structured text. tbc
How to structure PriceItems?

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum.

How to define distances?

Distances are defined with the help of "Figures". The distances to the relevant destinations (e.g. beach, city centre, shopping centre, airport, bus stop, ski lift etc.) are indicated as integers in meters.