In Attendance:

I. Welcome & Introductions
The meeting convened at 9:00 AM, and participants in the Infrastructure sub-committee were welcomed, introducing themselves and the companies they represented, sharing their experience and knowledge base with XML. Participants received a copy of the Agenda and the current HITIS Interface Specifications.

The purpose of this meeting was to provide recommendations to AH&MA about how to pursue mapping the HITIS standards in eXtensible Markup Language (XML), and to define the structure and format of the HITIS standards in XML as it relates to the object technology already defined in UML in Version 1.0

II. Rationale for XML Mapping Recommendations
Bill Geoghegan gave a brief explanation of the background of the Hospitality Industry Technology Integration Standards (HITIS) project, that originated with a Microsoft initiative; the Windows Hospitality Interface Specification (WHIS) group. The specifications developed by the Microsoft-sponsored group were COM-specific, object-oriented solutions. Realizing that there was a greater need within the industry for standards that operated on any platform, the WHIS Group submitted the specifications as Base Documents to the HITIS Project in an effort to uplevel the specifications into a neutral, open standard. This standards effort, sponsored by AH&MA, recognized two implementation mappings: one on the Windows platform and one on the Java language platform, and the Java - HITIS Implementation Solutions (JHIS) group was formed to assist the effort to map the HITIS standards to Java.

Upon attempting to implement the HITIS standards in the object model, it was discovered that the object paradigm was impacted, particularly in the Wide Area Network environment. In addition, interoperability issues remained between the two platform mappings. Both JHIS and Microsoft recommended to AH&MA that the emerging technology, eXtensible Markup Language (XML) be pursued as the primary language mapping. This state-of the art technology also has the advantage of serving as an intermediary between the old message-based environment and the remote object environment. The adoption of XML has gained industry momentum elsewhere; for example, the Open Travel Alliance (OTA) has determined that XML is the technology to be pursued across the boundaries of the travel and leisure industries.

III. Format of HITIS Standards - UML and XML
The current standards define a static data model, using class diagrams and associated descriptions of the attributes and operations. As HITIS moves forward into Phase II, there is a need to determine whether the format of the standards should be a UML model or a Document Type Definition, (DTD) that defines the XML message, or a combination of both. The committee was tasked to define the format of the HITIS Standards, considering both published and electronic format.

Bob Elliott shared his concept of a 3-tiered approach to the business portion of the HITIS standards documentation. The 1st level consists of business information and rationale for the HITIS standards to outsiders of the project, providing an overall understanding of the HITIS standards. The 2nd tier consists of explanatory material for a suite of standards; how they inter-relate and work with one another, and the reason for combining the group of standards under one particular technical committee, e.g.: Central Reservation Systems. The 3rd tier is a description of each individual standard illustrated by Use Cases that explains the business operational view to the non-technical person trying to understand the HITIS standards.

From an analysis and design perspective, it is important to document a system prior to implementation. The value in an Object-Oriented Analysis & Design (OOA&D) approach is to lend perspective to the business rules. Business use cases help define the dynamic interaction of users with systems as sequences of tasks are performed. In order to implement the standards, developers must be able to understand the intent of the specifications, and the use of sequence diagrams provides a way to document the dynamic model within UML that describes the relationship of the messages.

Adam Athimuthu presented several examples of sequence diagrams. He described sample sequence diagrams to define the dynamic relationship of the systems. Object models captures stateful representations to build distributed systems, but an object model assumes many things about the other system: what an object is called, the method of invocation, etc. The object model sequence assumes an interaction where the session remains connected so that the two parties talking to one another remember the context of other party.

Moving to XML changes the paradigm to transactional interactions. In an XML message, the UserName and Password for authentication is sent as part of a "handle" identifying the sender of the message. That handle becomes a "cookie" to remember who the other party is. The return message contains the same handle to identify the response to the original message from the sender. In this way, the physical extracted state from the session in implementation, and the length of the session is only the duration needed to send the message. Further, use of the "cookie" on subsequent messages abstracts the context server so that it does not have to be tied to a single machine. In fact, with the proper business agreements in place, one message is not limited to a single owner, but can accommodate a multi-vendor environment on the back end.

Ray Neimeir shared the experience of RezSolutions, who recently created working applications using XML as a means of data interchange. They started before DTD's and schema were well-established, and began by building an XML vocabulary that incorporated elements of DTD's. To build interchange formats, programmers traced log files to capture real transactions and determine what a system actually does. The examples of transactions were incorporated within a CDATA wrapper and became a part of their internal standard.

In the reservations scenario, booking transactions can vary widely. It is impossible to capture all of the behavioral aspects in XML, since business rules are not part of the DTD's. In addition, the DTD can carry messages that are communicated as nonsense to an application. RezSolutions created natural tags to name the parts of the document; such as Comments, and giving them valid tags provided the ability to peel out annotations. They used DTD syntax to define the values of attributes and placed them next to the message fields they describe. This means that the DTD is included within the XML document itself, rather than a reference location. Mark Stevenson shared a webpage location from the MSDN workshop that describes how data types are built into the XML schema in this manner. [http://msdn.microsoft.com/xml/c-frame.htm#/xml/default.asp]

The advantage of doing XML this way is that bilateral agreements are not needed. It is possible to send tags that describe the data sent, and encapsulate information between beginning tags and ending tags that are not part of doing business, e.g.: car rental tags etc. Implementations can choose to ignore other information, recognizing a smaller set of data within an entire message as long as it meets the minimum set of data needed to do business. This business model envisions a future of high-speed connectivity, allowing a superhighway of business transactions that answers the need for servicing over 10,000 hotels.

An XML oriented sequence diagram provides a way to document the dynamic model within UML and describes the relationship of the messaging payload. Latency in system response times can also be taken into consideration when sequence diagrams represent a higher level, coarse-grained sequence rather than individual operations that take place as one system prepares the message. Another important element is to document the full request/ response process by examples in XML, even though the examples may not be an actual component of the standards.

The Infrastructure sub-committee arrived at a consensus that the UML sequence diagrams are valuable for providing the dynamic model notation to describe the behavior of the transaction. As a picture is worth a thousand words, a graphical representation is useful to developers who wish to implement the HITIS standards for the design function precedes implementation. The diagrams should be kept at a high level, representing the sending and receiving systems, omitting processes that occur at the local level. The committee recommended adding sequence diagrams to represent the sequence of XML transactions and adding this component to the format of the standards documentation.

Recommendations for Phase II Standard format:
Retain the UML dynamic modeling notation augmented by XML Document Type Definitions (DTD's), incorporating the following components:

With reference to the XML components of the standard, every message (or message pair) is a discreet standard that requires its own DTD. When a request is sent, it should be done in a specific format, with required attributes and optional attributes defined, enforced by a DTD. The format of the response follows the same DTD. The operations that exist in the UML object model need to be separated and documented independently to clarify the relationship of operations in XML messages.

It was also recommended that the DTD's be supplemented by sample messages, documenting the full request/ response process by examples, even if the examples are not an actual component of the standards.

A DTD is not able to capture descriptions and explanations of the data element names, and is not very readable to non-technical folks. Additional descriptive information is used by the programmer in order to understand the context of how a data element is used, and ensures that it is used in a consistent way. Since operations cannot be represented in XML, operations need to be separated and documented separately in UML. Thus, with the combination of the two, the UML model is a back-up for what the DTD's cannot represent.

AH&MA Investment in a Modeling Tool
Bob Elliott pointed out the financial implications of publishing the standards in printed format versus investing in a modeling tool. From the AH&MA perspective there is a financial impact in using a case tool to document the standards. On the other hand, the creation of models may also provide a source of sustaining revenue, and the AH&MA may be able to charge a fee to support the HITIS project as opposed to placing the standards in the public domain.

AH&MA is trying to make a determination of whether to use a modeling tool. A UML model is useful to application builders as a design aid, and defines a single source for the standard. A recent article from Information Week indicated that the latest version of Rational Rose is able to export the XML (XMI) representation of an object model. If the UML model is able to generate DTD's, IDL's and schema, then it becomes a valuable tool for the repository of standard information; with placeholders for the component relationship, and the ability to check-in and check-out components on an as-needed basis.

The standards documents stand as they have been published, as the domain knowledge has already been established. The changes needed to make the standards complete include the addition of business descriptions and dynamic relationships. The existing documentation can be enhanced in the modeling tool, and converted to XML format. It is not necessary to convene a full technical committees again in order to determine the XML mapping, but a business use case sub-committee may be formed to assist in the enhancement of the UML documentation.

Design and Conformance to the DTD
If the information follows the data components specified by the HITIS standards, whether in a DTD or as a part of the message, it provides a common framework that maintains the neutrality of the standards.

Determining conformance of another system with the original message is usually done in real-time by a process of interactive discovery. Another way to determine the format of communication is by registering the DTD's with various online organizations, such as Biz Talk or XML.org. Yet another suggestion was that the AH&MA, or a contractor to AH&MA, could be a registration point, effectively acting as a 3rd party naming service where companies registering their conformance with HITIS messages would indicate what type of messages they accept. A query to the repository of this information could return all the transactions supported by a particular application. It was also recommended that messages be accepted in a bundle, such as certain components within the CRS technical committee standards, by individual standard, or by version, defining conformance by a subset or group of messages but not as granular as an individual message basis.

IV. Design of XML Template Document for HITIS Standards
The XML DTD's may not be adequate to fully explain the standards. The XML mapping needs to include the elements of the HITIS Interface Specification that define the data types, such as Currency, DateTime, HITIS enumerated types, etc., but a DTD supports only a string data format. If a Document Type Definition (DTD) needs extensions, the HITIS data types can be hand-coded as a way to begin mapping to XML. Currently, XML parsers are able to recognize and process DTD's.

The evolving standard of XML DATA schema can be added as an extension of the DTD's markup schema as an Appendix, and may become a part of the HITIS standards as the XML DATA standard matures. If parsers are changed to XML DATA, the messages can be converted to DTD's , allowing the DTD parser to send a string to the application if XML Data is not supported. The choice of parsers does not change the message that is passed across the wire.

A Schema determines whether the standard is extendable, or not, as one moves from the object definitions to XML. A closed model can have no additional tags; in an open model, tags can be added to the message as long as they are defined/well-formed. In a specific implementation, the XML Data standard can be used internally to validate a message. At high volume transactions, parsers can be turned off, using a high-speed hash check to determine well-formedness. Ray Neimeir, RezSolutions, recommended ignoring any unknown tag as opposed to rejecting an entire message, passing the validations on to a higher level. Messages are simply routed by transaction type, and the recipient application decides if the message can be processed.

For additional proprietary information, such as tag names, the Infrastructure sub-committee recommended using a namespace. A namespace identifies the ownership of the message and a business context outside of the standard. An additional DTD can be included with the HITIS message to define the namespace.

This assumes an open model for the HITIS standards and implies that the schema is extendable, with a namespace as the way to do the extension. If tags can be added, system architects should be aware of this capability and design their systems to accommodate this. Likewise, if HITIS chooses to extend the standard at some time, it is not obligated to conform with the individual extensions of other vendors, and the HITIS namespace should be clearly defined as the default for a HITIS compliant message.

V. Mapping HITIS Interface Specifications
The official standard remains the HITIS Interface Specification; that is, the data types represented in the object model, but the XML mapping needs a string representation of the HITIS-defined data types. These include numeric values such as a signed or unsigned integer, Currency, Percentage, etc., as well as the object data types unique to the HITIS standards.

In mapping the HITIS data types, the technical committee was tasked to determine if any commonality exists between representations currently in use. One particular concern is the DateTime data type. Bass and MSI, who have volunteered to do the sample mapping, will research sources for standard definitions of data types, such as XML.org, or Java "To" strings, etc., that may work well for internationalization.

Enumerated Types
The HITIS standards were designed on the premise that the messages are intended for an interface transaction between systems only, and not designed for a User Interface browser display. This is important in relation to HITIS enumerated types, because for a system to system interface, they can be mapped to their integer value, with the meaning of the value referred to a data table. If the interface were designed for user interface display, the values 1, 2, 3 etc., would need to be translated into the text that they represent, but using integer values in a system interface accommodates a multi-lingual environment.

The Infrastructure sub-committee recommended that HITIS Enumerated Types be kept as their numeric value in the XML mapping, and intercepted by the application processing it, using XSL to HTML for display. The DTD can establish values in an "At list" that refers to an external table.

Mapping the HITIS standards to XML implies doing away with object interfaces across the wire. Individual implementations may continue to use object architecture in local systems, but HITIS is concerned only with defining what is transferred between systems. In mapping the UML model to the DTD, some changes may be needed because the object model contains operations that cannot be represented in XML. The design of the UML notation is essentially a data model with the exception of the Session object, but the behavior identified in the Session operations need to be separated and documented independently. One proposal is for the name of the message to relate back to the method/operation call, using a naming hierarchy inside the DTD to clarify the relationship of operations in XML messages

Summary of Infrastructure Issues
The committee identified the following list of over-arching infrastructure issues that are basic to any message. An XML-Infrastructure sub-committee will need to define and agree on these items as all messages will contain these items:

Routing
Security
Namespaces
Versioning
Mapping of data types
Event handling strategy
Structure of basic message / response pairs

These items define the structure and format of the Message ID, and will become the "cookie" type of information that will identify and be a part of all messages.

The committee recommended that Versioning should continue to be backwardly compatible, recognizing that HITIS extensions to the original messages that may grow out of proprietary namespaces if they are officially adopted. HITIS or participating vendors may create XML schemas that reflect the DTD types, making them publicly available, even though they may not be a part of the standards. Donations may reside in a library, if accompanied by a liability release that released the vendors.

If additional elements were added to DTD's, especially mandatory elements, vendors would be faced with upgrading systems to the next version on a large scale. Hyder Ali noted that the namespace handled by BizTalk includes a version capability. The BizTalk message/response sequences also allow for conferencing, include tags for routing, and tags for the body of the message, etc. For example, handles can be included in <Context> tags.

Design and Conformance to the DTD's
A HITIS DTD is necessary for certification and compliance, but the use of a "validating" parser that checks a message against a DTD creates a great deal of overhead and is not recommended for real-time high volume processing. Some systems are looking at a volume of several messages processed per millisecond up to the potential speed of 4,000 messages per second. For processing at slower speeds, compliance can be determined by validating an XML message against an external DTD. In high volume transaction processing, parsers are used optionally to validate messages, and when they are turned off, a message is only checked for well-formedness, with validations passed on to the application level.

Four possible scenarios exist with respect to validation:

1. Validate every message to a remote DTD. (Usually used for purposes of testing)
2. Cache the DTD to the local and use the parser to validate locally.
3. Turn off validation to process high speed transactions, rejecting a message only for well-formedness.
4. Certain events trigger turning on validation for checking a message, (e.g.: a tag is mistyped and can be validated for rechecking)

In an XML message, one DTD for each request/response may be required, designating the mandatory fields for that operation. In a push model, only one message is needed, but a push / pull model requires both.

VI. Mapping HITIS Messages Event Handling
The communication subsystem should be used to handle the delivery mechanism of a message, and to supply a confirmation of the delivery. Further, the sending mechanism's transport / queuing mechanism must return an error code, if necessary, as opposed to embedding this function in a message/response pair. A generic message may contain a sequence ID and a return code which could be used as an acknowledgment, or as a return for a message that has not been processed properly.

When a message is sent, the sender has to supply a handle to identify the message. An application may choose to use a sequence number, or whatever tag is appropriate. Sometimes sequence numbers don't solve all the message dilemmas, as there are systems that exist that re-use sequence numbers. For example, when a reservation that was booked tentative is not committed, it is rolled back and discarded. Systems may be able to correlate sequence numbers to match, or the client can enlist the support of a transactional coordinator, but both sides must maintain a log file to trace the messages. There are up calls that can be used to track transactions, but that gets complicated when trying to communicate back to a 3rd system.

If a system has no response after a certain period of time, such as an e-commerce connection that must process an order and send it to a mainframe, the message is given to the server to process in the background. That processing can run continuously, but latency issues affect how long a system holds inventory, when the inventory is released, when the credit card is charged, and when a reservation can be considered approved and confirmed. The communication subsystem should be used to handle the delivery mechanism and to supply a confirmation of the delivery. In cases where inventory and payment for guarantees are involved, an acknowledgment is required.

In establishing benchmarks for the standards, such as the ability to react to an invalid message within a certain reaction time, there will be business rules that supercede the standards. As an example, the GDS requires a response within 7 seconds, but that requirement is not a part of the standards. This is an application architecture issue, and a description and a sequence diagram are required to define how the messages would interact. This has been solved in the GDS world, and it would be advisable to investigate how they have handled these issues in a 2-way interface.

Return Values
The Infrastructure sub-committee will need to establish a benchmark for the standards' ability to react to valid and invalid messages. There should be a generic notification of the inability to process a message. A response may indicate that the message was received, but the message may still not be able to be processed because of invalid information, returning an error code.

An XML message needs an application-oriented response to a violation of a data format. Invalid formats can be treated as though they were a blank field, but if this occurs in a mandatory field, it creates an exception. There is also a need to differentiate between a null value and an empty field.

If an operation is completed by use of an acknowledgment, that message could be piggy backed with numerous messages to the same server, sending the Confirmation # and identifier of the message together. In the scenario of a changed reservation this becomes more complicated. Often, inventory must be held while the change takes place. All the mandatory attributes must be resent in order to be validated to the DTD, using a value, such as #DELETE, to delete the old values and replace them with new values. Ray Neimeir offered to provide research into what would be needed to handle return values in this scenario.

The object model defines synchronous messages that wait for a round trip message return. In XML, asynchronous error message pairs could take the form of an inquiry about the error code, along with the language requested, with the anticipated response being the description of the error.

Session Operations
The current HITIS standards lend themselves very well to discrete messages, as there is no requirement for state to be maintained with the exception that the Session remains connected. Ron Kleinman suggested that the underlying architecture be allowed to define the connection. In this way, security becomes part of the underlying infrastructure of the message itself, and includes the data required for identification and authentication.

There are 2 options for handling the Session authentication:

1. Let the underlying architecture handle the security of the connection. If the interface is using a SSL (Secure Socket Layer) both systems must be able to assume the transport layer/ connection is secure.
2. Send a token with each message that includes the previous ID information, along with a profile request that refers to an internal XML document that defines the policies (e.g.: travel agent with override capabilities). Anyone having that token can operate with that set of rules.

The GDS's operate in a high volume environment, and get rid of state by sending self-contained messages. In this environment, authentication is one of the biggest roadblocks. By using a default profile allowing certain privileges, communication between parties that do not have a previous agreement is enabled.

VII. Transport Mechanisms
A HITIS message should be able to be transported over any mechanism capable of supporting XML. The transport mechanism is not part of the HITIS standard. The Application Programming Interface, (API) knows how to send and receive messages and can handle the transport. The consequences of the choice of transport mechanism to the standard is that if the transport layer can be counted on for confidentiality, encryption, etc., these functions could be delegated to it. Use of the API would take advantage of automatic queuing mechanisms, communication methods to talk to mainframes, etc., if the API is able to do so. If the transport layer does not perform these functions, then security needs to be defined by HITIS.

The Open Financial Exchange has defined a reference transport layer and recommends secure HTTP over TCP/IP. Defining the reference transport layer achieves greater plug and play between applications, but excludes certain other implementations, such as such as the new Hitachi telephone system that is transported over serial ports. Even with serial port transport, the mechanism that moves the message needs 1) an addressable entity and 2) a verb to or as the 1st character of an address for the implementation, and that must be agreed upon as part of the structure of the message.

The Infrastructure sub-committee decided that secure HTTP over TCP/IP is recommended, but not mandatory. Other systems, particularly those operating in a closed environment, may choose their means of transport, including any additional tunneling that may be a part of the transport layer.

Adam Athimuthu distributed copies of documents that included a sample mapping of HITIS objects to XML format and a proposal of five different architectural alternatives using different levels of object technology combined with XML to marshall data across the wire using COM or a message structure over TCP/IP. [Architecture Alternatives]

VIII. Role of AH&MA AH&MA will publish the DTD's as part of the HITIS standards documentation. The goal is to publish the standards and make the DTD's available to all of the hospitality industry so that the standards will become adopted and used widely. The bottom line is that the hotels have to believe in the value of the HITIS standards and request HITIS implementations from their suppliers.

As a means to determine compliance, vendors should be able to validate messages to the HITIS DTD's. This can be accomplished by placing the DTD's at an Internet location where they would be available. AH&MA or a contracted party would need to maintain the site. An alternative is to register the DTD's with online organizations such as XML.org or RosettaNet.

AH&MA entertained suggestions for revenue generation and ways to earn money to sustain the project.
The following suggestions were offered:

Seek a broad base of sponsorship at a lower dollar value.
Vendors may be willing to pay for certification in exchange for the privilege of displaying the HITIS certified logo.
AH&MA could host a "Connect-athon" to validate messages between vendors.
Conduct educational seminars explaining the standards.
There was interest at HITEC in obtaining the standards and AH&MA may be able to charging for printed copies.
Once the standards documentation is in marketable form, AH&MA could publish a catalogue of products.
If AH&MA established an industry-wide Hotel Code and Chain Code that identifies a unique property, AH&MA could maintain subscriptions and charge for annual registration.

Bob Elliott suggested that the master DTD's and the Correlation and Interface Specification document, consisting of the Data Dictionary and Interface Specifications, may have value to sell to the industry. Ron Kleinman cautioned that this idea has not worked in other industry verticals. Other organizations, such as the OPOS/JPOS effort found that they could not sell their data model standards in the retail industry. European efforts have had the same experience. They found that the architecture is not proprietary, but one might be able to charge in some way for the knowledge base associated with the standards. Bob noted that the AH&MA is registering the property rights and will hold the title and copyright to the standards.

A way to save money may be to leverage on the existing industry forums; for maintenance of the standards, development of schema, upgrading DTD's, and placing the standards components in a recognized standards repository to make it available to vendors. The mechanism for the maintenance and support of the HITIS standards will be decided by AH&MA, but for any entity hosting the website and doing the administration and support, vendor neutrality would be a key issue.

Mr. Bob Elliott suggested that the Correlation and Interface Specification document that consists of the Data Dictionary and Interface Specifications, as well as the master DTD's may have value to sell to the industry. Ron Kleinman of Sun Microsystems, Inc. cautioned that this idea has not worked in other industry verticals, and other organizations, such as the OPOS/JPOS effort found that they could not sell their data model standards in the retail industry. Like wise, the European efforts had the same experience. The architecture is not proprietary, but one might be able to charge for the knowledge base associated with the standards.

A way to save money may be to leverage on the existing industry forums, for maintenance of the standards, schema, DTD's upgrading and placing them in a recognized standards repository. The mechanism for the maintenance and support of the HITIS standards is to be decided by AH&MA, but for any entity hosting the website and doing the administration and support, vendor neutrality would be a key issue.

Bob Elliott noted that the AH&MA is registering the property rights and will hold the title and copyright to the standards. Donations of code and samples provided by vendors must be with the caveat that there is no liability involved in the release of the information into the intellectual property repository maintained by AH&MA.

An action item was noted for Bob Elliott to refer this question to AH&MA's legal counsel, Banks Brown.