Htng 2010 b_grsm_tech_spec_v1.1_final

Guest & Room Status Messaging
Specifications 2010B

Version 1.1
22 October 2010

Guest & Room Status Messaging Workgroup

Hotel Technology Next Generation Guest & Room Status Messaging Specifications 2010B
22 October 2010 Version 1.1

About HTNG

Hotel Technology Next Generation (HTNG) is a non-profit association with a mission to foster, through collaboration
and partnership, the development of next-generation systems and solutions that will enable hoteliers and their
technology vendors to do business globally in the 21st century; to be recognized as a leading voice of the global
hotel community, articulating the technology requirements of hotel companies of all sizes to the vendor community;
and to facilitate the development of technology models for hospitality that will foster innovation, improve the guest
experience, increase the effectiveness and efficiency of hotels, and create a healthy ecosystem of technology
suppliers.

Copyright 2010, Hotel Technology Next Generation

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright
owner.

For any software code contained within this specification, permission is hereby granted, free-of-charge, to any person
obtaining a copy of this specification (the "Software"), to deal in the Software without restriction, including without
limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, subject to the above copyright notice and this
permission notice being included in all copies or substantial portions of the Software.

Manufacturers and software providers shall not claim compliance with portions of the requirements of any HTNG
specification or standard, and shall not use the HTNG name or the name of the specification or standard in any
statements about their respective product(s) unless the product(s) is (are) certified as compliant to the specification
or standard.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-
INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Permission is granted for implementers to use the names, labels, etc. contained within the specification. The intent
of publication of the specification is to encourage implementations of the specification.

This specification has not been verified for avoidance of possible third-party proprietary rights. In implementing this
specification, usual procedures to ensure the respect of possible third-party intellectual property rights should be
followed.

The names Hotel Technology Next Generation and HTNG, and logos depicting these names, are trademarks of Hotel
Technology Next Generation. Permission is granted for implementers to use the aforementioned names in technical
documentation for the purpose of acknowledging the copyright and including the notice required above. All other use
of the aforementioned names and logos requires the permission of Hotel Technology Next Generation, either in
written form or as explicitly permitted for the organization’s members through the current terms and conditions of
membership.

Page 2


Table of Contents
1. DOCUMENT HISTORY.......................................................................................................................... 5
1.1 FUNCTIONAL CHANGE LOG ..................................................................................................................... 5
2. DOCUMENT INFORMATION ................................................................................................................. 6
2.1 DOCUMENT PURPOSE ........................................................................................................................... 6
2.2 SCOPE............................................................................................................................................. 6
2.3 AUDIENCE ........................................................................................................................................ 6
2.4 OVERVIEW ........................................................................................................................................ 6
2.5 DOCUMENT TERMS .............................................................................................................................. 6
2.6 REFERENCED DOCUMENTS ..................................................................................................................... 7
3. BUSINESS PROCESS ........................................................................................................................... 8
3.1 OVERVIEW ........................................................................................................................................ 8
3.2 ROLES ............................................................................................................................................. 8
3.3 BEHAVIOR ........................................................................................................................................ 8
3.4 USE CASES ....................................................................................................................................... 8
3.4.1 Check-In ................................................................................................................................. 8
3.4.2 Check-Out ............................................................................................................................... 9
3.4.3 Room Move ........................................................................................................................... 10
3.4.4 Guest Information Change ....................................................................................................... 11
3.5 MESSAGE FLOWS .............................................................................................................................. 11
3.5.1 Guest Checks In ..................................................................................................................... 11
3.5.2 Guest Checks Out ................................................................................................................... 11
3.5.3 Guest Moves Rooms ............................................................................................................... 11
3.5.4 Guest Changes Information ..................................................................................................... 12
4. SCHEMAS.......................................................................................................................................... 13
3.6 DESIGN DECISIONS ........................................................................................................................... 13
3.6.1 Common Schema Files ............................................................................................................ 13
3.6.2 Message Schema Files ............................................................................................................ 13
3.6.3 WSDL Construction ................................................................................................................. 13
3.6.4 Extension Points ..................................................................................................................... 14
3.6.5 OpenTravel Code Tables .......................................................................................................... 14
3.7 GUEST & ROOM STATUS MESSAGING MESSAGES ........................................................................................ 14
3.7.1 HTNG_CheckInNotification ....................................................................................................... 14
3.7.2 HTNG_CheckOutNotification..................................................................................................... 23
3.7.3 HTNG_RoomMoveNotification ................................................................................................... 26
3.7.4 HTNG_StayUpdateNotification .................................................................................................. 30
3.8 COMPLEX TYPES ............................................................................................................................... 33
3.8.1 Additional Language Type........................................................................................................ 33
3.8.2 Address Type ......................................................................................................................... 34
3.8.3 Affected Guests Type .............................................................................................................. 35
3.8.4 Affected Guest Type ............................................................................................................... 36
3.8.5 Company Name Type .............................................................................................................. 36
3.8.6 ComponentRoomsType ........................................................................................................... 37
3.8.7 ComponentRoom Type ............................................................................................................ 37
3.8.8 Country Name Type ................................................................................................................ 38
3.8.9 Customer Loyalty Type ........................................................................................................... 39
3.8.10 Customer Type....................................................................................................................... 40
3.8.11 Date Time Span Type.............................................................................................................. 41
3.8.12 Email Type ............................................................................................................................ 42
3.8.13 Formatted Text Text Type ....................................................................................................... 42
3.8.14 Guest Counts Type ................................................................................................................. 43
3.8.15 Guest Type ............................................................................................................................ 44
3.8.16 Hotel Reservation IDs Type ..................................................................................................... 45
3.8.17 Hotel Reservation ID Type ....................................................................................................... 45
3.8.18 Hotel Reservation Type ........................................................................................................... 46
3.8.19 Person Name Type ................................................................................................................. 48
3.8.20 Phys Chall Ind Type ................................................................................................................ 48
3.8.21 Preference Item Type.............................................................................................................. 49

Page 3


3.8.22 Preferences Type .................................................................................................................... 49
3.8.23 Preference Type ..................................................................................................................... 50
3.8.24 Profile Info Type ..................................................................................................................... 50
3.8.25 Profiles Type .......................................................................................................................... 51
3.8.26 Profile Type ........................................................................................................................... 52
3.8.27 Rate Plan Type ....................................................................................................................... 53
3.8.28 Related Traveler Type ............................................................................................................. 53
3.8.29 Room Element Type................................................................................................................ 54
3.8.30 Room Sharing Info Type .......................................................................................................... 54
3.8.31 Room Type Element Type ........................................................................................................ 55
3.8.32 Share Type ............................................................................................................................ 56
3.8.33 Sharing With Primary Type ...................................................................................................... 57
3.8.34 State Prov Type ..................................................................................................................... 57
3.8.35 Street Number Type ............................................................................................................... 58
3.8.36 Telephone Type...................................................................................................................... 58
3.8.37 Transport Info Type ................................................................................................................ 59
3.8.38 Unique ID Type ...................................................................................................................... 59
3.8.39 User ID Type ......................................................................................................................... 60
3.9 ATTRIBUTE GROUPS........................................................................................................................... 60
3.9.1 Birth Date Group .................................................................................................................... 60
3.9.2 Company ID Attributes Group .................................................................................................. 61
3.9.3 Currency Code Group .............................................................................................................. 61
3.9.4 Customer Loyalty Group .......................................................................................................... 62
3.9.5 Date Time Span Group ............................................................................................................ 63
3.9.6 Date Time Stamp Group .......................................................................................................... 63
3.9.7 Default Ind Group................................................................................................................... 64
3.9.8 Effective Expire Optional Date Group ........................................................................................ 64
3.9.9 Formatted Ind ........................................................................................................................ 64
3.9.10 Gender Group ........................................................................................................................ 64
3.9.11 Guest Count Group ................................................................................................................. 65
3.9.12 HTNG Payload Std Attributes ................................................................................................... 65
3.9.13 ID Group ............................................................................................................................... 66
3.9.14 Language Group ..................................................................................................................... 66
3.9.15 Loyal Level Group ................................................................................................................... 66
3.9.16 Profile Type Group .................................................................................................................. 67
3.9.17 Room Group .......................................................................................................................... 67
3.9.18 Signup Date Group ................................................................................................................. 67
3.9.19 Single Vendor Ind Group ......................................................................................................... 68
3.9.20 Telephone Attributes Group ..................................................................................................... 68
3.9.21 Telephone Info Group ............................................................................................................. 69
3.9.22 Telephone Group .................................................................................................................... 69
3.9.23 Unique ID Group .................................................................................................................... 70
5. IMPLEMENTATION REQUIREMENTS .................................................................................................. 71

Page 4


1. Document History
1.1 Functional Change Log

Version Date Comments
V1.0 24 Sep 2009 Included Check-in, Check-out, Room Move and Guest Information Change.
(2009B)
V1.1 22 Oct 2010 Replaced the use of xs:any by using OpenTravel’s TPA_Extensions; fixed StreetNumber
(2010B) type and added AffectedGuest element within HTNG_StayUpdateNotification.

Page 5


2. Document Information
2.1 Document Purpose
Hotel Hospitality Systems are increasingly being asked to provide greater property-wide service and management
utility, personalized guest experience delivery, and patron reward services management. To remain competitive,
hotel operators are being asked to provide increased in-room control and advanced services as standard features.
With this comes the need for greater in-room intelligence and open communications between room-based systems
and property operations systems. Hospitality Guest and Property Management System vendors, in turn, are
attempting to address these challenges by providing new features, functions and benefits in hopes of gaining greater
market share. This document describes how a vendor may utilize advanced service delivery message to
communicate with in-room systems, devices and services by using the HTNGs XML based Guest and Room Status
Messaging (GRSM) schemas. This results in providing guest and room status notification messaging derived from
industry standard schemas to insure increased cross industry system interoperability, flexible feature extensions and
faster service roll out.

2.2 Scope
This GRSM document targets the release of a specification providing the necessary components, including design
recommendations, WSDLs, XSDs, and Use Cases allowing a hospitality operator or hospitality system provider to
design and deploy subscription based services in line with best practices methods and procedures that meet or
exceed industry current web services standards specifications. Basic functionality of the GRSM service supports
publishing of Guest Room Event Notification. This GRSM document specifically addresses Guest Check-In, Guest
Check-Out, Guest Room Move, and Guest Information Change use cases. Future releases will expand on the
support of these use cases while adding additional use cases such as In-Room Control Notification, In-room
Entertainment Notification and In-room Communications Notification.

2.3 Audience
This document is intended to aid design, integration and deployment of hospitality services requiring interrogation
and notification of guest and guest room information services. The document specifically targets hospitality service
developers, integrators and operators.

2.4 Overview
Content contained in this document has been designed to assist the design, implementation and integration of
property wide event notification messaging based services requiring dynamic access to guest and room status
information. Document content provided by chapter to assist audience evaluation is as follows:

Chapter 3 - Business Process

This chapter explains the business process that corresponds to the messaging outlined in this document. This
includes use cases regarding Guests Checking In and Out of Hotel Rooms/Suites and also includes use cases related
to Guests Moving Rooms or changing important Guest/Profile Information. In addition to defining these use cases,
this chapter describes the different Business System Roles and the Messages that are defined in this specification to
enable these Use Cases.

Chapter 4 - Schemas

This chapter outlines the design decisions, messages, and common types that comprise the technical artifacts for this
certification release of GRSM v1.0 that can be found in a separate ZIP file included with specification.

Chapter 5 - Implementation Requirements

This chapter is intended to indicate the mandatory and optional requirements for implementing this specification.

2.5 Document Terms
For the purpose of this document, the following terms have been defined as follows:

Term Definition
Preferences Desired behavior and environment details associated with a Guest
Primary Share The Guest and/or Reservation that is considered default
Related Traveler An individual who is accompanying a Guest as part of a single reservation
Room Sharing More than one Guest is occupying a given Room, each responsible for their

Page 6


own charges
Suite A collection of rooms that can be sold as a single unit of inventory

2.6 Referenced Documents
The following table shows additional documents upon which this specification depends:

Document Title Location/URL
HTNG Web Services Framework http://collaboration.htng.org/specs/
Version 2.1.1
OpenTravel 2008B Release http://www.opentravel.org

Page 7


3. Business Process
3.1 Overview
This chapter explains the business process for which this specification is defining standardizing messaging. This
includes use cases regarding Guests Checking In and Out of Hotel Rooms/Suites. This also includes use cases
related to Guests Moving Rooms or changing important Guest/Profile Information. In addition to defining these use
cases, this chapter will describe the different Business System Roles and the Messages that will be defined in this
specification to enable the Use Cases.

3.2 Roles
There are two different roles that are defined for this specification:

 Room Stay Information Provider
 Room Stay Information Consumer

The Room Stay Information Provider issues key data related to Guests and Room Stay information about those
Guests. Examples of Room Stay Information Providers are Property Management Systems, Guest Information
Systems, and Customer Relationship Management systems.

The Room Stay Information Consumer needs access to key data related to Guests and Room Stay information.
Examples of Room Stay Information Consumer include In-Room Entertainment Systems, Door-Locking Systems, In-
room Control Systems (zone controller), Point of Sale Systems, and Energy Management Systems.

3.3 Behavior
This specification defines the messages for a Room Stay Information Provider to notify one or more Room Stay
Information Consumers regarding changes in Guest, Room, Reservation, or Stay information.

3.4 Use Cases

3.4.1 Check-In

Assumptions
1. The Guest has a reservation and the guest profile (either default or custom) and reservation type are in the
Guest/Property Management System (GMS/PMS). If the Guest is a walk-in, these details are setup via the
Front Desk staff. Details collected include:
a. Guest details such as name, address, credit card information
b. The Guest may setup or have information stored relating to particular features they wish the
property/room to honor.
i. Their language of choice (English, French, etc.). In this case we recommend the use of
ISO 639-2 (i.e., 3 character language codes)
ii. The temperature of the room
iii. Their normal wakeup time
iv. Favorite TV or Radio channels (i.e., the top 15 channels that would be easily accessible
by the Guest)
v. Security preferences they wish for the entertainment system
vi. A pre-recorded voice mail greeting they like to use
vii. Instructions on where to forward calls/notifications for missed calls when they are not
available
viii. Instructions relating to their privacy
c. Information relating to the room and types of services this Guest requires
d. Information relating to whether this Guest is sharing with other Guests; with this, a notation that
determines whether this Guest is the “Primary” guest in the room
e. Information regarding this guests participation with a Group
2. The property has a room for the Guest either through pre-allocation or allocation on the fly. The room status
is known and is most likely vacant/clean, however if the Guest is sharing, this is less important.
3. The interested systems have registered themselves for check-in event notification from the GMS/PMS and
will be notified immediately when the check-in event takes place.

Check-In Event
A Guest arrives at a kiosk, front desk or online site to check-in for the guest room.

Page 8


Following typical check-in procedures, the kiosk, front desk application, or online portal updates the GMS/PMS with
the Guest's check-in status and also updates the particular room (rooms in the case of a suite lock off).

If the room is currently occupied on guest check-in since this guest is part of a share, a notification is sent to
interested subscribers to update interested parties of this Guest’s arrival and preferences for the room. If this new
Guest is intended to be the primary share, then a smooth transition process might occur to set the preferences for
this Guest instead of the one(s) already in the room.

If the room is currently unoccupied on guest check-in then messages are sent to notify the subscribed systems that
the Guest is checking in. During the process, the following takes place:-

1. The PMS/GMS then sends messages to the door system to enable the Guest to enter their room(s)
2. Messages are sent to notify the guest room devices, which need to set guest preferences that the Guest has
checked in. This includes, but is not limited to the Entertainment system, Telephone system, Energy
management system, and Blind control system (shades). The notification message contains necessary guest
preference information from the GMS/PMS or a CRM system for that Guest to set the preferences
accordingly. This information is used to provision the services the Guest has requested. This includes the
telephone switch (PBX), In-Room Entertainment systems, and others which become activated with
appropriate limits and permissions.
3. Messages are sent to any appropriate staff management systems/tools to provision additional services for
the room, if not already in place (i.e., a cot or additional pillows).
4. If needed, a health check of all devices can be performed following the check-in notification to verify that all
of the devices are operational.

Current Status
Following the messaging/update process, each of the provisioned systems have context on the Guest/Reservation
and room and can be queried for their status and completeness upon providing their services. Each system needs to
be able to differentiate whether subsequent check-in and/or Guest information update events should reset their
status or just update the elements that have been changed (i.e., room temperature).

3.4.2 Check-Out

Assumptions
The Guest has a reservation and the guest profile, the reservation type(s) are in the GMS/PMS and the Guest has
been checked-in at the property.

Check-Out Event
A Guest arrives at a kiosk, front desk, uses an online site or device in the room, or makes a phone call to check-out
of the guest room. Following typical checkout procedures, the kiosk, front desk application, online portal, or
telephone system informs the GMS/PMS that the Guest is checking out.

If the room will remain occupied on guest check-out since this Guest is part of a share, a notification is sent to
interested subscribers to update interested parties of the new primary Guest’s details and a notification is made to
indicate that this Guest and reservation have been checked-out.

If the room will be unoccupied on guest check-out then messages are sent to notify the subscribed systems that the
Guest is checking out. During the process, the following takes place:

 If a device is unready for checkout, a corresponding message is issued by that device directly to the in-room
controller, kiosk, or related by clerk from PMS (e.g., Guest forgets wallet in safe while trying to checkout. The
safe receives the status message, provides information to the checkout device(s), and the guest is notified).
[The messages to support this functionality will be added in a future release]
 The Guest is asked for any forwarding details (i.e., email or mobile device information) and is asked if they wish
to have their guest folio and/or messages forwarded to these devices. In addition, the guest is asked if they wish
to save their phone greeting if they have updated it during their stay.
 A message is sent to subscribed systems/devices to notify them that the Guest is checked out and to set the
new status of the room. Room status may be vacant dirty, vacant clean, vacant out of service or other statuses
as defined by the GMS/PMS.
 Immediate results or events that happen after a default grace period has successfully expired, during which no
activity has been detected in the room,:
o Devices are deactivated (e.g., TV system turns off)
o Devices are “depersonalized” (e.g., personalized TV screen, blinds, lighting, energy management
system turning up the heat setting and/or requesting the default profile in order to set the
temperature)

Page 9


o Un-provision permissions / limits are reset
 After Guest has checked-out and room has been un-provisioned, subscribing systems would be notified of this
final state (i.e., housekeeping system notified of readiness for cleaning)

Current Status
Following the messaging process, each of the provisioned systems have context on the current status of the room
and can be queried for their status and completeness at providing their services.

During housekeeping or maintenance activities, the room may need to be provisioned into a quasi-state that provides
adequate services for the function being performed (i.e., lights on, blinds open, and phone and entertainment system
operational but not available for charging during housekeeping activity).

3.4.3 Room Move

Assumptions
The Guest has a reservation and a guest profile and the Guest has been checked-in at the property. The guest may
have been in the property for some time and may also be staying in a room in a guest share arrangement.

Room Move Event
The Guest requests a room move (from room #1) and following the normal availability check, a new room (room #2)
is identified for this Guest or group of Guests (in the case of a share). The various scenarios are described below.

If room #1 will remain occupied after the Guest moves rooms since this Guest was part of a share, the following will
need to occur:

1. A guest notification is sent to interested subscribers to update them with old information for room #1. This
will establish the new primary Guest’s details. If the Guest staying in the room was originally the primary,
no changes to the room should take place. If one of the Guests staying in the room becomes a new primary
Guest, all of the devices in the room need to migrate to the new Guest’s settings in a graceful manner. A
mechanism to establish a new key/access privileges will be offered to the room #1 Guest(s).

2. The same guest notification is used to update interested parties with new information for room #2. A
selected Guest will be nominated as the primary and their guest preference settings will provided. A new
key/access privileges will be issued to the Guest(s) in room #2.

3. Systems involved in providing guest amenities will need to determine if any amenity needs to be moved
from room #1 to room #2.

If room#1 will be unoccupied on room move, then messages are sent to notify the subscribed systems that the
Guest(s) are undergoing a room move and the following will need to occur:

1. If a device is unready for check-out, a corresponding message is issued by that device directly to the in-
room controller, kiosk, or related by a clerk from PMS (e.g., Guest forgets wallet in safe while trying to
checkout. The safe receives the status message, provides information to the checkout device(s), and the
Guest is notified).
2. A message is sent to subscribed systems/devices to notify them that the Guest is moving rooms and to set
the status of the old room (room #1) to “room check needed”. If the room move is due to a fault condition,
the old room is set “out of service” due to the fault.
3. Actions that happen after a default grace period has successfully expired, during which no activity has been
detected in the room, include:
a. Devices are deactivated (e.g., TV system turns off)
b. Devices are “depersonalized” (e.g., personalized TV screen, blinds, lighting, energy management
system turning up the heat setting and/or requesting the default profile in order to set the
temperature)
c. Un-provision permissions / limits are reset
4. After Guest has moved and room has been un-provisioned, subscribing systems would be notified of this
final state (i.e., housekeeping system notified of readiness for a check).
5. A room move message is sent to all systems subscribed to the message. The message includes details of
the old (room #1) and the new room (room #2) by doing this.
a. Amenity systems can organize the transfer of key items
b. A graceful transfer of purchased services can take place (i.e., internet, movies, room service)

Page 10


c. Equipment is provisioned in the new room (room #2) in preparation for the Guest’s arrival

Current Status
Following the messaging process, each of the provisioned systems have context on the current status of the rooms
and can be queried for their status and completeness at providing their services.

During housekeeping or maintenance activities, the room may need to be provisioned into a quasi-state that provides
adequate services for the function being performed (i.e., lights on, blinds open and phone and entertainment system
operational but not available for charging during housekeeping activity).

3.4.4 Guest Information Change

Assumptions
1. The Guest has checked into a property and all of the necessary information has been exchanged between
the servers of the differing vendor types.
2. All servers from the known vendors have registered for notification when guest information is changed.

Guest Information Change Event
When the Guest enters their room, they notice that their name is misspelled on the devices that provide a
personalized welcome message. These devices may include but are not limited to the telephone and the television.
The Guest calls the front desk to notify them of the error and the front desk personnel correct the mistake in the
GMS/PMS.

A notification process ensures that the following occurs:
 The GMS/PMS sends a message to all of the servers that have registered for the guest information change
event. This event will contain the relevant guest information for each Guest registered in that room. The
event will also identify the primary Guest. At this time, we believe guest information includes the Guest’s
name and their preferred language. Additional information may be added as the specification progresses.

Alternate Scenarios
A guest name change may also be required if multiple Guests were checked into the same room/unit and the primary
Guest checks out. In this situation, a guest information change event would be used to notify all of the servers.

Current Status
Following the change in the GMS/PMS, downstream systems receiving the guest information change event should
perform a comparison on their current record keeping for the Guest. If the Guest information has been updated,
these changes should be immediately applied. If there is a conflict on an update (i.e., the downstream system
believes it will affect the integrity of its record keeping), an exception should be noted and highlighted to the
downstream system’s administrative support.

3.5 Message Flows
This section will describe each Use Case and the messages that have been defined in order to enable the use cases.

3.5.1 Guest Checks In
The HTNG_CheckInNotification message is a one-way message sent from a Room Stay Information Provider to a
Room Stay Information Consumer containing information about one or more Guests that have checked into a single
Room/Suite, whether or not other Guests are already in that Room/Suite.

3.5.2 Guest Checks Out
The HTNG_CheckOutNotification message is a one-way message sent from a Room Stay Information Provider to a
Room Stay Information Consumer containing information about one or more Guests that have checked out of a
single Room/Suite, whether or not other Guests remain in that Room/Suite.

3.5.3 Guest Moves Rooms
The HTNG_RoomMoveNotification message is a one-way message sent from a Room Stay Information Provider to a
Room Stay Information Consumer containing information about one or more Guests that have moved from one
Room/Suite to another Room/Suite within the property, whether or not other Guests remain in the previous room, or
other Guests are already in the new room.

Page 11


3.5.4 Guest Changes Information
The HTNG_StayUpdateNotification message is a one-way message sent from a Room Stay Information Provider to a
Room Stay Information Consumer containing information about a Guest whose profile or other information has
changed.

Page 12


4. Schemas
This chapter outlines the design decisions, the messages, and common types that comprise the technical artifacts for
this certification release of GRSM v1.1 that can be found in a separate ZIP file included with specification.

3.6 Design Decisions
This section is intended to capture some details and explanations of how the technical artifacts (schemas and
WSDLs) were constructed and why they were created differently than previous HTNG work product.

3.6.1 Common Schema Files
The best practice of constructing a common data object schema file as a place to capture simple and complex
schema types that can be reused with several different messages has been implemented for a few of the HTNG web
service certification releases. However, these data objects were not defined according to any other standard, and
because they are in a namespace that is specific for the messages and version they support, this common schema
file is not as useful for future specification building as it could be.

This first release of the Guest and Room Status Messaging specification attempts to take this concept a few more
steps forward. This is done by creating a common complex schema types file (HTNG_ComplexTypes_2010B.xsd)
and a common simple schema types file (HTNG_SimpleTypes_2010B.xsd). The majority of the complex and simple
types that are defined in these files are based on the 2008B release of the OpenTravel specification. This was done
in order to enable reuse of well-defined data objects from an organization where much overlap exists. However, it
was decided that in order to not create an unnecessary dependency on OpenTravel, in the case where their future
specs change how certain types are defined, copy the definitions and put them into an HTNG namespace.

This specification also takes this concept of a common data object schema files to another level by putting the
common files (both HTNG_ComplexTypes_2010B.xsd and HTNG_SimpleTypes_2010B.xsd) in a namespace that is
not dependent on either the GRSM messages being created or the version of the specification. This namespace
(http://htng.org/Common) is intended to not be changed in future versions of this specification or other
specifications that might reuse some of these common schema files. Creating a common namespace allows pieces of
code that are based on the data objects in the common files to not change with future releases, thus ideally allowing
more flexibility and reusability. However, the fact that there is one namespace means that a given data object entity
within these files should not be changed in future releases, otherwise there would be conflicting definitions of the
same type. Instead, it is intended that new data objects would be created that are new or that extend existing
types. Although there will be one common namespace for future releases of common schema files, in order to not
confuse implementers of the specifications, the name of the common files will be labeled with the release they were
intended for.

3.6.2 Message Schema Files
Following the OpenTravel message architecture for constructing schemas, each GRSM v1.0 message has been
defined in a separate schema file. Unlike previous releases of web service message definitions, these message
definitions are named (HTNG_xxxx.xsd) and are in a namespace (http://htng.org/2010B) that is independent of this
GRSM specification. Whilst this is a deviation from the Framework 2.1.1 specification, it is an evolutionary step to
enable better reuse of these messages. The fact that previously released messages were defined in a namespace
specific to that specification did not allow a future specification to easily consume these messages, thus creating a
situation where the same or very similar message was defined twice. Therefore, in order to minimize the existence
of this problem, these GRSM messages are defined without regards to the specification for which they were created.

3.6.3 WSDL Construction
The WSDL for this first release of the GRSM specification follows very similar guidelines as the message schema files,
as in it has been defined in a namespace that is independent of the specification for which it is was intended
(http://htng.org/2010B). In addition to following the guidelines of the HTNG Framework 2.1.1 regarding separating
the schemas from the WSDLs, this specification has taken the extra step to separate the WSDL into three different
files. This was done in order to simplify the implementation of production web services based on these WSDLs. In
reality, this GRSM specification only goes as far to standardize the portType definitions of the WSDL since this is
defining the interfaces for creating a web service that uses the messages that are created. For those who choose to
implement according to the HTNG Framework 2.1, which is not all of the vendor community, the WSDL bindings can
be standardized around the SOAP/HTTP transport for the portTypes defined in this specification. The actual WSDL
service definitions are implementation-specific details, as they might contain other bindings and other portTypes that
are not part of this specification. It was this thinking that led to the splitting of the WSDL into three separate files:
HTNG_Ports.wsdl, HTNG_Bindings.wsdl, and HTNG_ServiceExamples.wsdl. For those who only want to only
implement the portType with proprietary bindings and services, the HTNG_Ports.wsdl file will not have to be

Page 13


modified, and for those who want to define their services using HTNG Framework 2.1, then the HTNG_Bindings.wsdl
can be used without modifying the service-specific details. The HTNG_ServiceExamples.wsdl file is only included in
order to validate the correct construction of the WSDL and to give implementers a guide of how to implement these
services.

The splitting of this WSDL into three files, where HTNG_ServiceExamples.wsdl includes HTNG_Bindings.wsdl, which
includes HTNG_Ports.wsdl, works smoothly as best as known with the code generation tools that are typically used in
the industry. Examples of this code generation have and will continue to be posted on the HTNG Collaboration Site.

3.6.4 Extension Points
For this release, extension points in the schema files were created according to the HTNG Framework 2.1, which says
to include an xs:any element within any complexType definition which is intended to be extended in the future. This
allows any implementation-specific content to be added to the message without having to change the standardized
schemas. Thus, if an implementer wants to extend this GRSM v1.0 specification, it is expected they would create
their own schema file that defines their specific content and then reference both the HTNG standardized schemas and
their own proprietary schema files in the XML instance documents. However, in an effort to avoid any non-
determanistic content models, we allow use of the xs:any type within a TPA_Extensions element.

3.6.5 OpenTravel Code Tables
Because this specification has built many data objects in a style that is based on OpenTravel 2008B release, it has
also defined several code table types that will have a need to reference back to the OpenTravel code tables, which
are kept in a spreadsheet and schema form within the OpenTravel organization. Due to OpenTravel’s desire to make
the code tables backwards-compatible, there should not be any conflicts with using the latest version of the
OpenTravel code table in conjunction with this specification. However, in any cases where conflict occurs, this
specification was created with the 2008B OpenTravel release in mind, thus this version should be fallen back upon in
such cases.

3.7 Guest & Room Status Messaging Messages
The following sections describe in more detail the four different messages defined as part of the GRSM v1.1
specification.

3.7.1 HTNG_CheckInNotification
The HTNG_CheckInNotification message is defined within the HTNG_CheckInNotification.xsd schema definition file,
which imports the HTNG_ComplexTypes_2010B.xsd schema definition file. The following diagram and table detail
each of the high level elements in the HTNG_CheckInNotification. More details for each complex type referenced can
be found later under “Complex Types.”

HTNG_CheckInNotification
<xs:element name="HTNG_CheckInNotification">
<xs:complexType>
<xs:sequence>
<xs:element name="AffectedGuests" type="common:AffectedGuestsType" minOccurs="1"/>
<xs:element name="RoomSharingInfo" type="common:RoomSharingInfoType" minOccurs="1"/>
<xs:element name="TPA_Extensions" type="common:TPA_ExtensionsType" minOccurs="0"/>

Page 14


</xs:sequence>
<xs:attributeGroup ref="common:HTNG_PayloadStdAttributes"/>
</xs:complexType>
</xs:element>
Name Type Data Type Use Comments
AffectedGuests element AffectedGuestsType required These are the guests that are checking
into the hotel room.
RoomSharingInfo element RoomSharingInfoType required This is a snapshot of the room sharing
information (whether other guests are
checked in or not).
HTNG_PayloadSt attributeGroup
dAttributes

Simple Check-In Message Example

John Smith has checked into the hotel for his reservation (Jan. 10, 2010 to Jan. 12, 2010 in a KingSize Room) at 10
AM. He has received a special internet rate for his King size room, potentially because he is a Gold member in the
WorldTravelers loyalty program. When he checks into the hotel, he is assigned room 1201, where he looks forward
to seeing his preferences for TV channels (Discovery, Learning Channel, History Channel) set on the entertainment
system.

The following XML example is an HTNG_CheckInNotification message that would be sent for the simple check-in
scenario above:

<?xml version="1.0" encoding="UTF-8"?>
<tns:HTNG_CheckInNotification TimeStamp="2009-07-10T16:20:47Z"
xsi:schemaLocation="http://htng.org/2010B HTNG_CheckInNotification.xsd"
xmlns:tns="http://htng.org/2010B" xmlns:htng="http://htng.org/Common"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns:AffectedGuests>
<htng:AffectedGuest ReservationID="RES123" GuestID="GST123" />
</tns:AffectedGuests>
<tns:RoomSharingInfo>
<htng:Room RoomID="1201">
<htng:RoomType RoomTypeCode="KING" InvBlockCode="GRP123" IsRoom="true">
<htng:RoomDescription Language="en-us" Formatted="true" TextFormat="PlainText">
Ocean View King Room
</htng:RoomDescription>
</htng:RoomType>
</htng:Room>
<htng:PrimaryShareDetails DepartureTime="10:00:00" ArrivalTime="16:00:00">
<htng:Reservation MarketCode="T" CreateDateTime="2008-12-17T09:30:47Z"
ResStatus="Reserved"
CreatorID="CRS123" SourceOfBusiness="Internet" LastModifierID="AGT123"
LastModifyDateTime="2008-12-17T09:30:47Z">
<htng:HotelReservationIDs>
<htng:HotelReservationID ResID_Date="2008-12-17T09:30:47Z"
ResID_SourceContext="CRS123" ResID_Type="14" ResID_Value="RES123"
ResID_Source="CRS123" />
</htng:HotelReservationIDs>
<htng:RoomTypes>
</htng:RoomType>
</htng:RoomTypes>
<htng:RatePlans>
<htng:RatePlan RatePlanCode="RAT123" RatePlanName="Special Internet Rate" />
</htng:RatePlans>
<htng:GuestCounts>
<htng:GuestCount AgeQualifyingCode="10" Count="2" />
</htng:GuestCounts>
<htng:TimeSpan End="2010-01-10" Start="2010-01-12" />
<htng:AvailableCredit>0</htng:AvailableCredit>
</htng:Reservation>
<htng:Guest GroupEventCode="GRP123">

Page 15


<htng:Profiles>
<htng:ProfileInfo>
<htng:UniqueID Type="1" ID_Context="CRS123" ID="GST123" />
<htng:Profile ProfileType="1">
<htng:Customer Language="en-us" VIP_Indicator="false" LockoutType=""
CurrencyCode="USD" BirthDate="1967-08-13" Gender="Male" DecimalPlaces="2">
<htng:PersonName>
<htng:NamePrefix>Mr.</htng:NamePrefix>
<htng:GivenName>John</htng:GivenName>
<htng:Surname>Smith</htng:Surname>
</htng:PersonName>
<htng:Telephone PhoneUseType="3" Extension="101" PhoneLocationType="6"
PhoneTechType="1" PhoneNumber="3035560" FormattedInd="false"
DefaultInd="true" CountryAccessCode="" AreaCityCode="847" />
<htng:Email EmailType="1"
DefaultInd="true">john.smith@htng.org</htng:Email>
<htng:Address Type="2" FormattedInd="false" DefaultInd="true">
<htng:StreetNmbr>650</htng:StreetNmbr>
<htng:AddressLine>E. Algonquin Road</htng:AddressLine>
<htng:AddressLine>Suite 106</htng:AddressLine>
<htng:CityName>Schaumburg</htng:CityName>
<htng:PostalCode>60173</htng:PostalCode>
<htng:County>Cook</htng:County>
<htng:StateProv StateCode="IL">Illinois</htng:StateProv>
<htng:CountryName Code="US">United States</htng:CountryName>
</htng:Address>
<htng:CustLoyalty ExpireDateExclusiveIndicator="true"
AllianceLoyaltyLevelName="Gold" SignupDate="2007-08-13"
ExpireDate="2012-08-13" SingleVendorInd="SingleVndr"
PrimaryLoyaltyIndicator="true" EffectiveDate="2007-08-13"
CustomerType="Bisiness" LoyalLevelCode="100" LoyalLevel=""
TravelSector="3" MembershipID="123456789" VendorCode=""
CustomerValue="Standard" ProgramID="WORLDTRAVELERS" Remark="" />
<htng:AdditionalLanguage Code="fr" />
</htng:Customer>
<htng:UserID Type="1" ID_Context="PMS123" ID="4864" PinNumber="1234" />
<htng:Preferences>
<htng:Preference PreferenceType="Television">
<htng:PreferenceItem UnitOfMeasure="Channel"
Description="Discovery Channel" Value="DSC" SortOrder="1" />
Description="The Learning Channel" Value="TLC" SortOrder="2" />
Description="History Channel" Value="HIST" SortOrder="3" />
</htng:Preference>
</htng:Preferences>
</htng:Profile>
</htng:ProfileInfo>
</htng:Profiles>
<htng:ArrivalTransport>
<htng:TransportInfo Type="14" LocationCode="MCO" ID="132" Time="2010-01-10T14:00:00"
/>
</htng:ArrivalTransport>
<htng:DepartureTransport>
/>
</htng:DepartureTransport>
</htng:Guest>
</htng:PrimaryShareDetails>
</tns:RoomSharingInfo>
</tns:HTNG_CheckInNotification>

Check-In with Suite Message Example

John Smith has checked into the hotel for his reservation (Jan. 10, 2010 to Jan. 12, 2010 in an Ocean View Suite) at
10 AM. He has received a special internet rate for his suite, potentially because he is a Gold member in the
WorldTravelers loyalty program. When he checks into the hotel, he is assigned Suite 100 (which consists of Rooms

Page 16


1201 and 1202), where he looks forward to seeing his preferences for TV channels (Discovery, Learning Channel,
History Channel) set on the entertainment system.

The following XML example is an HTNG_CheckInNotification message that would be sent for the check-in with suite
scenario above:

<htng:Room RoomID="STE100">
<htng:RoomType RoomTypeCode="STEOCN" InvBlockCode="GRP123" IsRoom="true">
Ocean View Suite
</htng:RoomType>
<htng:ComponentRooms>
<htng:ComponentRoom RoomID="1201">
</htng:RoomType>
</htng:ComponentRoom>
<htng:ComponentRoom RoomID="1202">
<htng:RoomType RoomTypeCode="PARLOR" InvBlockCode="GRP123" IsRoom="true">
Ocean View Parlor Room
</htng:RoomType>
</htng:ComponentRoom>
</htng:ComponentRooms>
</htng:Room>
<htng:RoomTypes>
<htng:RoomType RoomTypeCode="STEOCN" InvBlockCode="GRP123" IsRoom="true">
Ocean View Suite
</htng:RoomType>
</htng:RoomTypes>
<htng:RatePlans>
</htng:RatePlans>
<htng:GuestCounts>
</htng:GuestCounts>
</htng:Reservation>
<htng:Profiles>
<htng:ProfileInfo>

Page 17


<htng:PersonName>
</htng:PersonName>
</htng:Address>
<htng:PhysChallName PhysChallInd="false"></htng:PhysChallName>
</htng:Customer>
<htng:Preferences>
</htng:Preference>
</htng:Preferences>
</htng:Profile>
</htng:ProfileInfo>
</htng:Profiles>
/>
/>
</htng:Guest>

Room Sharing Check-In Message Example

John Smith has checked into the hotel for his reservation (Jan. 10, 2010 to Jan. 12, 2010 in an Ocean View King
Room) at 10 AM. John has received a special internet rate for his room, potentially because he is a Gold member in
the WorldTravelers loyalty program. John’s brother Joe Smith will be staying with him, but he has not checked into
the hotel yet. When John checks into the hotel, he is assigned Room 1201, where he looks forward to seeing his
preferences for TV channels (Discovery, Learning Channel, History Channel) set on the entertainment system.
Although Joe has different preferences for his TV channels for the room, John is the primary guest in the room and
his preferences will most likely be used.

Page 18


The following XML example is an HTNG_CheckInNotification message that would be sent for the Room Sharing
Check-In scenario above:

</htng:RoomType>
</htng:Room>
<htng:RoomTypes>
</htng:RoomType>
</htng:RoomTypes>
<htng:RatePlans>
</htng:RatePlans>
<htng:GuestCounts>
</htng:GuestCounts>
</htng:Reservation>
<htng:Profiles>
<htng:ProfileInfo>
<htng:PersonName>
<htng:SurnamePrefix></htng:SurnamePrefix>
</htng:PersonName>

Page 19


</htng:Address>
</htng:Customer>
<htng:Preferences>
</htng:Preference>
</htng:Preferences>
</htng:Profile>
</htng:ProfileInfo>
</htng:Profiles>
/>
/>
</htng:Guest>
<htng:SharingWithPrimary>
<htng:Share DepartureTime="10:00:00" ArrivalTime="16:00:00">
ResStatus="Reserved" CreatorID="CRS123" SourceOfBusiness="Internet"
LastModifierID="AGT123" LastModifyDateTime="2008-12-17T09:30:47Z">
<htng:RoomTypes>
<htng:RoomDescription Language="en-us" Formatted="true"
TextFormat="PlainText">
</htng:RoomType>
</htng:RoomTypes>
<htng:RatePlans>
</htng:RatePlans>
<htng:GuestCounts>
</htng:GuestCounts>
</htng:Reservation>
<htng:Profiles>
<htng:ProfileInfo>

Page 20


CurrencyCode="USD" BirthDate="1967-08-13" Gender="Male"
DecimalPlaces="2">
<htng:PersonName>
<htng:GivenName>Joe</htng:GivenName>
<htng:MiddleName></htng:MiddleName>
<htng:SurnamePrefix></htng:SurnamePrefix>
<htng:NameSuffix></htng:NameSuffix>
<htng:NameTitle></htng:NameTitle>
</htng:PersonName>
<htng:Email EmailType="1" DefaultInd="true">
joe.smith@htng.org
</htng:Email>
<htng:BldgRoom BldgNameIndicator="false"></htng:BldgRoom>
<htng:CompanyName CodeContext="" CompanyShortName="HTNG"
Department=""
Division="" TravelSector="" Code="HTNG">
Hotel Technology Next Generation
</htng:CompanyName>
</htng:Address>
CustomerType="Business" LoyalLevelCode="100" LoyalLevel=""
<htng:AdditionalLanguage Code="en-us" />
</htng:Customer>
<htng:Preferences>
Description="Cable News Network" Value="CNN" SortOrder="1" />
Description="Bloomberg Business Television" Value="BLOOM"
SortOrder="2" />
</htng:Preference>
</htng:Preferences>
</htng:Profile>
</htng:ProfileInfo>
</htng:Profiles>
<htng:TransportInfo Type="14" LocationCode="MCO" ID="132"
Time="2010-01-10T14:00:00" />
<htng:TransportInfo Type="14" LocationCode="MCO" ID="456"
Time="2010-01-12T09:30:00" />
</htng:Guest>
</htng:Share>
</htng:SharingWithPrimary>

Page 21


Related Traveler Check-In Message Example

John Smith has checked into the hotel for his reservation (Jan. 10, 2010 to Jan. 12, 2010 in an Ocean View King
Room) at 10 AM with his wife Sally. John has received a special internet rate for his room, potentially because he is
a Gold member in the WorldTravelers loyalty program. When John checks into the hotel, he is assigned Room 1201,
where he looks forward to seeing his preferences for TV channels (Discovery, Learning Channel, History Channel) set
on the entertainment system.

The following XML example is an HTNG_CheckInNotification message that would be sent for the Room Sharing
Check-In scenario above:

</htng:RoomType>
</htng:Room>
<htng:RoomTypes>
</htng:RoomType>
</htng:RoomTypes>
<htng:RatePlans>
</htng:RatePlans>
<htng:GuestCounts>
</htng:GuestCounts>
</htng:Reservation>
<htng:Profiles>
<htng:ProfileInfo>
<htng:PersonName>
</htng:PersonName>

Page 22

Htng 2010 b_grsm_tech_spec_v1.1_final

Htng 2010 b_grsm_tech_spec_v1.1_final

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to Htng 2010 b_grsm_tech_spec_v1.1_final

Similar to Htng 2010 b_grsm_tech_spec_v1.1_final (20)

Htng 2010 b_grsm_tech_spec_v1.1_final