APEX Implementation Pilot - Q1 2007 Update

On March 21-22, an intrepid group of pioneers met in Ft. Lauderdale to figure out how the meetings and group travel industry will use this APEX stuff. Like all explorers, we discovered that the path before us will be easier than we thought it was before we started, but harder than we had hoped for.

Time to Test the "Exchange" part of APEX

As the name (Accepted Practices Exchange) says, APEX is about exchanging data between trading partners in the meetings and group travel industry. As described previously, last year we developed three XML specifications within the Open Travel Alliance to help event planners exchange data related to:

• Request for Proposals (RFP) - meetings in search of a facility
• Hotel Rooming Lists - attendees who need rooms in a group block
• Event Specification Guide (ESG) - meeting information for the planner to share with the hotel

This year, our goal is to implement pilot programs with specific industry partners who will use these XML standards to electronically transfer data from one proprietary system to another.

The Plan

First, our group (the APEX Technology Advisory Committee) reviewed our options and selected a strategy. We decided that each trading partner (meeting planners, CVBs, and hotels) would be responsible for creating their own "translator", or software routine that converts data from their proprietary database format into the standard APEX XML.

Notice that the APEX standards do not specify the infrastructure surrounding the XML exchange. Eventually, we expect to provide guidelines about this infrastructure, which may consist of SOAP web services or https GET/POST methods. We expect the data exchange methods will require an authentication layer, in order to make sure the other application should have access to the requested data, and a version control layer, since the OTA standards are published twice a year and will undoubtedly undergo changes as the community learns from experience.

Next, we agreed that we want to offer a human-readable version of the (machine-readable) XML documents. This will make the XML useful in situations where only one trading partner adheres to the APEX standards, and it should help developers validate their XML translators.

For now, we decided to not tackle the Exhibitor versions of the Event Specification Guide (ESG) or Functional Setup Order (FSO), and we decided not to produce an XSLT standard for the "page layout" of the Rooming List standard, since this is legacy report format leftover from the days before Excel and e-mail.

The Preparation

Before starting a software development project, you should define how you will validate that the result meets your expectation. For APEX, we agreed upon a validation method for trading partners to test their translator routines that produce XML documents:

• The XML must be well-formed. Any XML editor (or browsers like Internet Explorer) will tell you if the resulting XML document is formed correctly according to the W3C standards.
• The XML must validate against the OTA XML schema (XSD). Good editors like XML Spy will compare XML documents to an XSD standard and instantly identify areas of non-compliance, e.g. if an email address is not in the correct format.
• The XML must have data in the correct fields. Developers will be required to download the sample XML documents from OTA, enter the data into their application database, and then produce XML using their export translator. The resulting document should match the sample that you started with, otherwise, for example, you may be putting a person's first name into the last name field and not notice the error during the first two tests.

The Path

After discussing our past experiences with XML data transformation and exchange, the team selected the Altova MissionKit Enterprise Edition for the implementation process. (The enterprise edition is required because the OTA schemas are complex "nested" xml schemas, which aren't supported by the professional edition.)

• XMLSpy - OTA uses this editor to produce the XML standards, and it offers simple validation of XML documents against XSD schemas.
• StyleVision - We used this editor to produce XSLT files that map "machine-readable" XML documents into "human-readable" HTML or PDF formats.
• MapForce - This tool will allow each trading partner to map their proprietary database fields to the XML Schema standard fields, which is the first step to building a "translator" for the APEX standards.
  

The Journey

Well, if only you could imagine how excited this bunch of computer geeks were after producing a Plan, Preparation, and Path on the first day. After dinner and a couple of drinks at the Irish pub that night, we actually thought we might knock this thing out on the second day. Unfortunately, reality set in after about 2 hours of struggling with Stylevision, but we created enough transformation tools to confirm that we are on the right path.

The journey continues - contact us know if you want to join it.