1. OpenTravel 2.0
Creating Messages from Objects
January 2014
© 2014 OpenTravel.org

2. Tens of thousands of OpenTravel message structures
carry tens of millions of messages
between trading partners every day
2
OpenTravel formed as a
member funded, not-for-
profit organization.
OpenTravel produces the
first open standards for
the travel industry.
OpenTravel architects
its new model driven
schema product.
OpenTravel provides the preferred open source XML standard for
the travel and leisure industry.
1999 2001 2014

3. OpenTravel 1.0 Message Suite
3
OpenTravel’s flagship schema product is a mature messaged-based
specification that covers multiple travel segments.

4. 2.0 XML Object Suite addresses growing complexity
in travel industry distribution
Model driven messaging
• Focus on exchanged
information – not
message structure
• Manage the model - not
individual messages
• Models are easy to
extend
• Smaller messages
4
Programming friendly
 Improved productivity
 Faster to market

5. OTM-DE uses an Information Model
to Simplify Development & Maintenance
5
In most cases manually
developed schema do not
map well to applications’
information models which
means
• Additional coding is
required to deal with the
mismatch
The goal instead is to let
tooling (Model Designer,
Repository & Compiler)
handle the serialization of
the objects for sending
across the network
OpenTravel Model – Development Environment
(OTM-DE)

6. Implementers create light-weight or functionally-rich
transactions by “binding” to a collection
Model contains organized
collections of summary,
detail and query attributes
and elements:
• Light-weight example:
Flight notifications for
mobile devices
• Functionally rich example:
PNR management
6

7. OTM-DE
The OpenTravel Development Environment
• Features and tools that help you develop messages and other artifacts with the OpenTravel
Model (OTM)
OTM is an expression of the OpenTravel 2.0 XML Schema Best Practices
• Defined by the OpenTravel Architecture Workgroup (AWG)
The OTM-DE includes three parts:
• Model Designer tool
• Repository for OTM artifacts
• Build Automation Utilities (Message Compiler, XML Schema and WSDL service
descriptions)
7

8. 2.0 Developers Assurances
• 2.0 Best Practices = simpler classes
• XML Identity = class identity
 Controlled Vocabulary = consistent classes
 XML Namespaces = class packages
 Final state = code that does not change
• Versioning = minimum effort for new releases
• Extensions = reuse standard code
• Facets = designs that meet differing needs
• Tooling = consistency
8

9. Based on 10+ years of shared experience
Open Travel 2.0 Best Practices
• Optionality vs. Facets
• Code Lists vs. Enumerations
• Attribute Groups vs. Value with Attribute (VWA)
• Local Types vs. Global Types & Aliases
• Choice Groups vs. Custom Facets
• Chameleon Types vs. Namespace Bindings
9

10. Optionality shift to Facets
• Most of OpenTravel 1.0
elements and attributes are
optional
• Impossible to tell what is really
required and when
10
• OpenTravel 2.0 facets allow for
varying levels of detail for the
same type
• Fields are optional only if there
is a business reason

11. Code Lists shift to Enumerations
• Code lists are maintained
separately from the code
• Not part of the formal interface
contract (when code values
change)
11
• Codes are maintained as part of
the schemas themselves
• Developers can use code-assist
features of their development
tools
Data in external
detailed spreadsheet

12. Attributes shift to VWA (value with attribute)
• Attribute groups are not visible
in most generated binding code
• Impossible for developers to
know which attributes are
related
12
• Values-with-attributes define
separate types for each group
• Separate binding classes
generated for each group

13. Local Types shift to Global Types & Aliases
• Local anonymous types are not
reusable or compatible in
generated binding code
13
• Aliases create global elements
that are all bound to a single
type

14. Choice Groups shift to Substitution Groups
(custom facets)
• In binding code, choice groups
look exactly the same as
sequences
• Impossible to know what is
included in the choice
14
• Custom facets use object-
oriented features to allow
choices based on the facet type

15. Chameleon Types shift to Namespace Bindings
• Chameleon schemas bind types
to each namespace that includes
them
• Binding classes may be
duplicated numerous times
15
• Namespace-assigned types are
bound once
• The single copy of each type is
re-used throughout the
generated binding code

16. 2.0 Web Services are built from
2.0 XML object templates
• Services: Operations exposed to the service consumer
• Business Objects: Real world items you want the
service to take an action against
• Core Objects: Real world items that are the same
regardless of business context
• Value with Attributes: a value and associated
collection of attributes
• Enumerations: A list of values which may be closed
or open (extensible)
• Simple Objects: XML simple types which contain a
single data value
16

17. Hierarchy of XML Objects represent lowest layer
17
Web Service
Model
Service Operation
Business Object
Core Object
Business Object
Core Object
Value with Attribute
VWA
Enumeration
Simple Type
Core Object
Value with Attribute
VWA
Enumeration
Simple Type
Value with Attribute
VWA
Enumeration
Simple Type
Atomic Type
Enumeration
Simple Type
Atomic Type
Simple Type
Atomic Type
The OpenTravel Model Designer is used if
you need to make extensions to the
OpenTravel Model (OTM) shown here.
Value with Attribute
VWA

18. Simple Type
Simple Type is the most granular building block in an XML
model ― a named definition of an object with descriptions,
other documentation, example values equivalents and
constraints
Simple Types can be further defined by adding constraints:
• Pattern (limit valid characters)
• Character Length (min / max )
• Fraction Digits (max allowed)
• Numeric Characters (total for decimal based type )
• Min /Max Inclusive/Exclusive (lower and upper bounds
on the range of value)
18
Atomic Type
Simple Type

19. Enumeration
Enumeration can be closed...
19
Enumeration
Simple Type
Atomic Type
• Non-implementer extensible
enumerated list
• Static list values
or open…
• Implementer extensible
enumerated list
• List limited to <= 100 values
• Reserved “Other_” literal
• When compiled the open enumeration creates
an XSD simpleType for the enumerated list
and a complexType with simple content to add
the extension attribute

20. VWA – value with attributes
• For example, the currency and currency
code in the Amount VWA relate to the
amount value. VWA can also have an
Empty value in which case it is simply a
group of attributes.
• When compiled, a VWA becomes a single
XSD complexType with simpleContent. The
value is the base type of the simpleContent
to which all attributes are added.
20
Value With Attribute (VWA) is a collection of
attributes that relate to the value and exist as a simple
type, open enumeration or VWA.
Value w/ Attribute
Enumeration
Simple Type
Atomic Type

21. Core Object
Core Object describes multiple representations of a real-
world object that is the same regardless of business
context—an Address is an Address—in searching for golf
courses and booking an airline ticket.
A Core Object defines up to six different representations
(facets) that can be used as types in other objects.
• Simple Type
• Summary
• Detail
• Roles
• Simple List
• Detail List
21
Core Object
Value w/ Attribute
Enumeration
Simple Type

22. Business Object
A Business Object defines multiple representations for
a single real-world item or concept.
A Business Object always includes three represen-
tations or “facets”:
• ID
• Summary
• Detail
A Business Object can also define properties or sets of
properties to query or find items or to be used in specific
business contexts:
• Custom facet
• Query facet
22
Business Object
Core Object
Value w/ Attribute
Enumeration
Simple Type
Example of checked
bag intended for use
in air travel.

23. Service Operation
An OTM Library can define a service complete with 1 or more
operations and Request, Response and Notification messages.
• Service messages are compiled into the XSD schemas and the operations and service
details are used to create the WSDL service description.
• A library can have only one service.
• User can delete notifications and responses as appropriate for their service interaction
pattern.
23
Web Service
Model
Service Operation
Business Object
Core Object
Value w/ Attribute

24. Developer Support
ODN or OpenTravel Developers Network is an umbrella website to offer
members and public various levels of access to product releases,
publication & project calendars, educational webinars and conference
materials in addition to:
• Forums
• Member sponsored projects to develop new model-driven, object-based schema
• Travel industry glossary
• OpenTravel Model Designer, Compiler (Build Extensions) and Remote Repository
• Common object and segment specific libraries
• Specification commenting and member review
24

25. OpenTravel 2.0 Horizon
OTM-DE
OpenTravel
Libraries
Public
Release
Community
Development
25

26. OpenTravel 2.0
Creating Messages from Objects
For more information
info@opentravel.org
www.opentravel.org
© 2014 OpenTravel.org