OTDS workshop: Introduction to the Open Travel Data Standard

Workshop: Introduction to OTDS
Structures, Conditions, Price calculation
©OTDS e.V., April 2018, info@otds.de

Agenda
 OTDS – what is that?
 What is XML?
 Basic structure of OTDS
 Conditions and PriceItems
 Price calculation with OTDS
 PriceItems

Overview of the first workshop
 What is OTDS and why do we need it?
 What led to initiating OTDS?
 Correlation between travel catalogue and data
delivery

What is OTDS and why do we need it? 1/3
 Description of a data standard for the
interpretation of data for travel offers
 The data recipient shall be enabled to process
the data in such a way, that the travel offers
may be searched for and booked.
 Similar as in a cooking recipe:
– The cook transmits information on how ingredients
have to be processed in order to result in a tasty
meal.

 Advantages
– Consistent workflow
– 100% specified
– Comprehensible processing
– Extensive processing reports
– Better data quality in practice (problems may be addressed more easily)
– Better to be validated than flat data
– Contains discounts for children and senior citizens
– Enables incremental data deliveries
– Optional and integrated Add-on services
– Extended offer attribution
– Easier to produce for provider
– Shortens the total process chain
– Not limited to the national market
– Expandable also in the long-term view
– Fit for future requirements

 Disadvantages vs. flat data deliveries
– Higher complexity than in flat data deliveries (e.g. INFX,
INFX2, etc.)
– More complicated to process
– Counting the offers is more complex
– According to the scenario the processing might take longer
– According to the scenario the data volume might be larger
– The speed of processing an OTDS-data delivery with
unknown structures is difficult to predict

What led to initiating OTDS? 1/3
 Travel catalogue
 Info-Fax
 INFX
 INFX2
 AICP and other data formats
 KATI and derivatives
– Component based
– Consists from single CSV-files
– Facilitates the exchange of very large data volumes
– No standardization
– No child discounts, fixed prices for children , etc.
– No transparency for the market

 EDF
– Component based
– XML based
– More standardized than KATI
– But still implicit, tour operator dependent interpretations
– Discounts for children integrated
– proprietary, thus not openly accessible
– Not interested in general transparency
 In the context Player/HUB
Risk of losing access to the travel offer data

 OTDS as a market initiative of several distribution systems
(Traveltainment, Bewotec, Traffics)
– Component based
– 100 % standardized
– A free standard with comprehensive documentation, that is permanently
refined and (with restrictions) openly accessible
– Practically a documentation for the tour operator, how is data are to be
interpreted
– No unnecessary redundancies
– Also apt for flat data
– Contains all components for search and booking
– Contains the attributes/properties of the offer
– Price calculation
– Booking parameters
– Flexibly expandable
– XML based

What is XML? 1/3
 Explanation on the basis of an XML-Struktur for cooking recipes
A specific
recipe
This is
served
More
recipes
This is
served
This is
served

What is XML? 2/3
The element „Liquid“
The value of the
element „Liquid“
The Values of the attributes of
The element „Liquid“
The attributes of the
elements „Liquid“
This is an element as well

There are context sensitive
default values in OTDS as well
A list of values
No list
Default values
What is XML? 3/3

Which tool to use to work with XML-files?
 Notepad ++ as XML-Viewer
– Prerequisite: XML Module must be installed.
– Functionalities of NotePad++:
• Color coded display of Attributes etc.
• Folding up or out Elements by using „-“ and „+“ on the left edge
• „PrettyPrint“ functionality
o Menu ->Plugins ->XML-Tools -> PrettyPrint with LineBreaks
• Check XML Syntax
o Menu ->Plugins ->XML-Tools -> Check XML Syntax
• Validieren eines XML
o Menu ->Plugins ->XML-Tools -> Validate Now

What is a XSD? 1/4
 Description of the format
– of single elements
– of values allowed
– of the interpretation of the data delivered
 Limitation of the data delivery to the extent defined
 Options for validation before sending off the data and
after recieving them
 Reduction to the values allowed, respectively special
charaktes for Strings
 Special software for displaying XSD (Oxygen/Altova)
 For OTDS the content is also incorporated in the
Technical Specification

What is a XSD? 2/4
Example of a XSD for a cooking recipe:

What is a XSD? 3/4
Number
Choice/Sequence
Optional
Attribute are not to be
found multiple times

What is a XSD? 4/4
 Definitions for the attribute „Unit“
The values of the
elements may also
be limited

Extract from the Technical Specification of OTDS
Link: https://forum.otds.de/documentation/public/de/technisch/otds_technisch.html
User: OTDS
Passwort: 0nlined0ku ("o" written as Zero)

Correlation between catalogue and data delivery

Basic structure of OTDS 1/2
All rules for products
All brands contained
All accommodations contained
All flights contained
All additional services
All rules for combined components

Basic structure of OTDS 2/2
Contains all data for PMI913
Contains all data for PMI914
etc.

Components of the Accommodation
Various accommodations
Selling level of accommodations
Various boards
Various rooms
Selling level of the room
The Keys each unambiguously identify a component
Example:
- Accommodation Key=„PMI913“
- SellingAccom Key=„W15_PMI913“
- Unit Key=„DZT“
- SellingUnit Key=„DZT_33122202“

Overview of the next workshop
– Framework
– Properties of the offer
– Booking parameter of the offer
– Occupancies

Offer variations
6 different rooms 2 board types
different
occupancies
 This catalogue page exists in the summer as well as in the winter catalogue

Components of the Accommodation
For each season (Winter/Summer)
one SellingAccom
two board types
6 rooms with a price line each

Example for several price lines in a Unit
3 price lines for the same
room with different
occupancies

Set-up of the SellingAccom
Bis jetzt kennen wir den Aufbau der SellingAccom in dieser Form:Reality is just a little more complex:
Free markings
Booking parameters
Attributes
Price components
Limitations
Component shift

View of XML as compared to XSD
XML XSD

Catchment Airports
Availabilities
View of the Accommodation structure

View of the SellingAccom structure

View of the Board- / Unit structure

Definition of possible occupancies
View of the SellingUnit structure

Properties of the offer
Hotel name: Mon Port
Place: Puerto Andratx
Stars: 4
Unit name: Superior with Seaview
Unit property: seaview
Board type: HP
Board: Half-board
Included services:
- Transfer
- Rail & Fly
Unit type: Superior

A condition that has to be fulfilled in
order to make this PropertyGroup valid.
OTDS Properties of the Accommodation

OTDS Properties of the Accommodation

Optional priority
Optional condition
Valid for all SellingAccoms contained
Valid for all Units contained
Valid for this Board
Valid for all SellingUnits contained
Valid for this SellingUnit
Theory of the Property 1/6

Gradual eradication
1. Review of the Condition of the
PropertyGroup
2. Collecting the valid properties according
to the XML-Order
3. Overwriting of identical properties
1. Higher priority wins
2. Following properties overwrite prior
ones
Theory of the Property 2/6

OTDS-Report – Query Parameter
List of Query Data
Brand : FTI
Servicecode : PMI913
Roomcode : DSHM
Traveldate : 2015-09-16
Duration : 9
Departure Airport : DUS
Destination Airport : PMI
Occupancy : 25,25
DataTimestamp : 2015-07-12T23:40:02.750000z
A valid offer has been found

OTDS-Report – Offer Components 1/2
Report for the valid offer

OTDS-Report – Offer Components 2/2
The resulting offer is:

OTDS-Report – Properties of the Offer 1/4

Hotel code: PMI913
Room code: DZT, DZ, etc.
Breakfast : F
Half-board : H
Travel type: PAUS
Booking Parameters

GlobalArea ServiceArea PersonArea
Analogies of OTDS Booking Parameter 1/2
 Division in Areas

Field=„BrandCode“ Field=„TravelType“
„RequestCode“ „ServiceCode“ „ServiceFeatureCode“ „BoardCode“ „DateStart“ „DateEnd“
„Title“ „Age“
A Service line only has
field with identical
Source- and Class values
Analogies of OTDS Booking Parameter 2/2
 Each relevant field in the booking mask is represented by a „Field“ in OTDS

Booking Parameters 1/2
 BookingParameter with
identical „Name“ and „Field“
overwrite each other.
 Different „Names“ are sorted
by index and then listed
 If „Name“ or „Index“ are
missing, then Name=„Default“
and Index=„0“

Identical Field
Name=„Default“
Index=„0“
Both parameters together result in „DSMH“
Booking Parameters 2/2

Theory of Booking Parameters 1/2

Working it off step by step:
1. Reviewing the Condition of the
BookingGroup
2. Collecting the valid booking parameters
according to the XML-Order
3. Overwriting / Adding / Deleting identical
bookiing parameters
a) Sorting firstly ascending by priority,
then by XML-Order
b) In overwriting, the subsequent
booking parameter succeeds
Theory of Booking Parameters 2/2

Booking Parameters in a Report

Brand-Definition 1/2
 Each product offer can be offered for several Brands.
 The Brands used for an OTDS-delivery are defined by
the Products.
 Global booking definitions such as
– Title (of a person)
– Age (of a person)
– Date allocations for the components
in general are defined within the Brand.

Definitions of occupancies
for each room
resp. for each price line
Occupancies of Rooms 1/3

An Occupancy consists from
several groups of persons with
identical properties
The groups of persons may
contain restrictions regarding the
age and the number of persons

2 persons with the age 13 years and older
0-1 person aged 1 year or older
 This is how the tour operator delivers occupancies:

Example:
2 adults (aged 18 or older)
+ 1-2 children up to the age of 13
+ 0-1 Baby (max. 1 year of age)
The Occupancy only refers to the fact, which room occupancy is
possible.
Which person is eligible for which discounts or surcharges is managed
within the PriceItems.
Example for an Occupancy

Overview for the next Workshop
– Restrictions
– Price Items

Date conditions
Booking date
Rolling FB
Duration condition
Weekday condition
Occupancy condition
Conditional Tags
Generic Tags
Key condition
Tag condition
Departure- and arrival airport
Price condition
Number of days
Number of persons
Theory of Filters and Conditions 1/2

All conditions have to be fulfilled
One condition has to be fulfilled
The condition may not to be fulfilled
Only if this condition is fulfilled…
… then also this condition has to be fulfilled
Theory of Filters and Conditions 2/2

All single conditions have to be fulfilled in order to have the AND-condition fulfilled.
Only one single condition has to be fulfilled in order to have an OR-condition fulfilled.
AND
Condition 1
Condition 2
OR
AND and OR

AND and OR and NOT in Correlation
Conditions can be interlaced into each other
fulfilled,
if
fulfilled, if
fulfilled, if

fulfilled,
if
fulfilled, if
fulfilled, if
<Imply>
<If>
</If>
<Then>
<Duration Source="Accommodation">
<Min>01</Min>
</Duration>
</Then>
</Imply>
then
IMPLY
Conditions can be interlaced into each other

Definition of the component
Definition CheckIn/CheckOut/Stay
Containment of dates
Theory of Date-Condition

I = CheckIn
S = Stay
O = CheckOut
Possible values for DayType
Possible Values for Source
(only those before parenthesis)
Theory of DayTypes and Source

Definition of the component
The duration defines the number of date changes between CheckIn and CheckOut.
Theory of Duration

Possible values for Source
(only those before parenthesis)
Here the duration for all components is identical.
Only OnewayFlight and BookingClass would have a duration = 0
This is a standard offer: it contains no overnight flight or other extras
Duration of a Standard Package Offer

The Various Special Cases of Duration 1/4
A package offer with an overnight flight on the outbound flight
Scenario: Departure 22:30 p.m. -> Arrival 10:30 a.m.
Depending on Source different values result.

A package offer with overlapping on the outbound flight
Scenario: Departure 0:20 a.m. -> Arrival 3:30 a.m.
-> An overnight stay starting the day prior to arrival is needed/booked
One checks in even before one departs. But that‘s just the way it is...

A package offer with a gap on the return flight
Scenario: Departure as before, return flight 0:20 a.m. -> Arrival time not relevant
-> No overnight stay is needed/booked for the previous day of the return flight

A package offer with season change on November 1st

Tags are markers attached to components.
Tags are used for product rules and price calculation.
Example:
A discount campaign is published in the travel catalogue:
• All hotels printed on blue pages offer 10% discount.
• All hotels printed on red pages offer 30% discount.
The matching PriceItem looks like this:
What are Tags? 1/2
page color RED
page color BLUE
page color RED
Day Price
Global discounts“>

 Tags attached to products are also popular.
– Those tags allow to steer, that certain can
accommodations can not be used for package offers
 But also the combination of outbound- and return
flights is frequently managed with the help of Tags.
– Tags in those cases generally represent Airlines or Airline
groups, that may be combined or maynot be combined
with each other.
What are Tags? 2/2

OTDS-Report – Tags 1/2

OTDS-Report – Tags 2/2
List of Tags of all components

Product Definition 1/3
Definition of Product-Tags
Product booking parameters
Main components
Restrictions of the product

An accommodation
constructed from 2 seasons
Specific restrictions
regarding the season change
Chronological sequence

Product consisting from
one accommodation and
a flight
Restrictions:
(among others) which flight
shall be combined with which
accommodations

Examples for Product Restrictions
 e.g. a hotel may only be sold as HotelOnly
 Certain hotels may only be sold in travel agencies
 Certain flights may only be combined with certain
hotels
 In general only specific duration shall be offered
 … and any other conditions desired…

DefinedComponent consisting from
an outbound- and a return flight
Restrictions, which outbound flight
shall be combined with which return
flight
All DefinedComponents with the appro-
priate role are used
Defined Components

Room prices with breakfast
For each room and period
Board surchargeFlight basic price = 291,-
Discounts for
specific persons
Early bird booking discounts
Longterm discounts
Prices

PriceItem
Absolute
Percent
Day price 25 Euro per day
Travel surcharge 150 Euro per trip
Person surcharge 100 Euro per person
Board surcharge 5 Euro per day
Holiday surcharge 50 Euro
10% early bird booker
20% surcharge for single room
7=6 (100% discount on the first or last day)
30% discount on the 2nd child
5% discount for senior citizens
Theory of Price Items 1/3

Properties of PriceItems
• PriceItem classification
• value
• Per day – per trip
• Per person – per room
Conditions of PriceItems
• Normal conditions
• Impact conditions

Properties of PriceItems
• Value
• Effect (relation to Absolute-Class)
Conditions
• Normal conditions
• Impact conditions

Overview of the next Workshop
– PriceItems
– Impact conditions
– ConditionalTags
– Working with the documentation / Prezi

Theory of the Cost Matrix
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8
3rd Person
2nd Person
1st Person
Cost matrix of a 7-day-trip for 3 participants
Travellers: two adults (age 35, 34) and one child (12)
P(35)
P(34)
P(12)
The trip starts October 26th.
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Main season (Season A) lasts until October 31st.
Season A Season L

Tag 1 Tag 2 Tag 3 Tag 4 Tag 5 Tag 6 Tag 7 Tag 8
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Season A Season L
Daily price 25,- € for main season (Season A)
Daily price 10,- € for low season (Season L)
Basic price per person: 210,- €
Child discount -30% on daily price for children up to age 14.
Early booker discount on daily price and basic price: -5% for bookings until 31.7.
25 25 25 25 25 25
25 25 25 25 25 25
25 25 25 25 25 25
10
10
10
30 30 30 30 30 30 30
30 30 30 30 30 30 30
30 30 30 30 30 30 30
-5% -5% -5% -5% -5% -5% -5% -5%
-5% -5% -5% -5% -5% -5% -5% -5%
-5% -5% -5% -5% -5% -5% -5% -5%
-30% -30% -30% -30% -30% -30% -30% -30%
Allocations of PriceItems
3rd Person
2nd Person
1st Person

Structure of the Cost Matrix 1/4

3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Season A Season L
3rd Person
2nd Person
1st Person

25,- € 30,- €+-5% -5%0,95 0,95x x = 52,25 €
Calculation of a Cost Node

52,25
3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Season A Season L
52,25 52,25 52,25 52,25 52,25 52,25
52,25 52,25 52,25 52,25 52,25
3rd Person
2nd Person
1st Person

25,- € 30,- €+-5% -5%0,95 0,95x x = 45,13 €-30%0,70x
Calculation of a Cost Node

52,25
3. Person
2. Person
1. Person
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Season A Season L
52,25 52,25 52,25 52,25 52,25 52,25
52,25 52,25 52,25 52,25 52,25
45,13 45,13 45,13 45,13 45,13 45,13 34,82 0
38 0
38 0 351,50
351,50
305,60
149,63 149,63 149,63 149,63 149,63 149,63 110,82 0 1008,60
3rd Person
2nd Person
1st Person

3. Person
2. Person
1. PersonP(35)
P(34)
P(12)
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Season A Season L
25 25 25 25 25 25
25 25 25 25 25 25
25 25 25 25 25 25
10
10
10
-30% -30% -30% -30% -30% -30% -30% -30%
The following PriceItems use all Impact Conditions:
Impact Conditions 1/5
3rd Person
2nd Person
1st Person

 Normal (Non-Impact)
– The Condition is fulfilled, if one of the days between 24.12. – 31.12. is included in the trip.
– The PriceItem then is valid on all stay days.
 Impact
– The Condition is only fulfilled on the stay days 24.12. to 31.12.
– The PriceItem then only is valid on those stay days.

Normal (Non-Impact) Impact

Only valid for persons between 3 -12 years of age
Is valid for the 1st, 3rd, and 7th person (descending order by age)
Is valid for the 3rd and 4th oldest person of
those persons that are aged between 2 and 6

Filtering of the days
Which days
Definition of a recurrent period
Which days of which component shall be considered?
Stay days only? Or stay days including CheckOut?
Days addressed
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
Repeat = „5“ and Indices= 1 3
DayIndex

Negative Index
Positive Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-8 -7 -6 -5 -4 -3
1 2 3 4 5 6
-2
7 8
-1
Negative Index
Positive Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-7 -6 -5 -4 -3 -2
1 2 3 4 5 6
-1
7
Standard without IntervalType (IntervalTypeDefault = „Stay“)
IntervalType = „CheckInOut“
Negative Index
Positive Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-1 -2 -4 -3 -2 -1
1 2 3 4 5 6
Filter = 26.10. - 31.10.
DayIndex – Negative Indices and Filter

Negative Index
Positive Index
26.10. 27.10. 28.10. 29.10. 30.10. 31.10. 01.11. 02.10.
-7 -6 -5 -4 -3 -2
1 2 3 4 5 6
-1
7
Standard
Until = 3
or Until = -5
From = 4 or
From = -4
The last 2 From = -2
The first 2 Until = 2
DayIndex – From/Until

 Similar helpful descriptions are to be found in the
online documentation „Thematical Specification“
(available to members of the OTDS association only)
e.g. search here for:
- DayIndex
- DayPriceIndex
- PersonIndex
Working with the Thematical Documentation

Formally
ConditionalTags are conditioned marks of components.
In reference with ImpactConditions specific days or persons can be tagged.
Value area
Condition
ConditionalTags theoretically can be placed at all components:
- Accommodation, SellingAccom, Board, Unit, SellingUnit
- Brand, Product, GlobalValue
- ReturnFlight, OnewayFlight, BookingClass
- Addon, Service, ServiceFeature
In practice
What are ConditionalTags? 1/4

ConditionalTags are used for specific conditions in Filters and Conditions.
In general they are applied with PriceItems.
Formally
In practice
Reference to component
Reference to Class

This is the corresponding PriceItem:
Definition of ConditionalTags
Value area of the definition
Condition of the definition
ConditionalTag condition

Definition of ConditionalTags
Value area of the definition
Condition of the definition

3. Person
2. Person
1. Person
Trip on 26.03. for 7 days for 2 adults + 1 child
P(35)
P(34)
P(8)
26.03. 27.03. 28.03. 29.03. 30.03. 31.03. 01.04. 02.04.
C-Tag „Season“= A
C-Tag„PersonType“=A
Imaginary Processing within the Cost Matrix
3rd Person
2nd Person
1st Person

OTDS-Report – ConditionalTags 1/2

Valid for day 0-6
Valid for all days/persons
Not valid
Valid for day 2-5 and…
Valid for person 1+2
OTDS-Report – ConditionalTags 2/2

OTDS workshop: Introduction to the Open Travel Data Standard

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to OTDS workshop: Introduction to the Open Travel Data Standard

Similar to OTDS workshop: Introduction to the Open Travel Data Standard (20)

Recently uploaded

Recently uploaded (20)

OTDS workshop: Introduction to the Open Travel Data Standard