OpenTravel publishes specifications twice a year, and the specification naming convention is:
Year + Alpha
So the first specification published in 2006 was 2006A and the second was 2006B. Download the most recent specification, and start with the ReadMe file and the Message Users Guide, which contains use cases and instance documents for most of the messages in the OpenTravel library. Match the message description with the business problem to be solved and review that message.
Often users of the specification say they would like the specification to be more rigid and contain more implementation guidance. That rigidity would not reflect the flexible way travel suppliers and distributors meet customer demands in today’s travel marketplace. Every set of travel trading partners has different messaging requirements, so OpenTravel specifications are designed to allow trading partners to implement the messages in the way that best suits their business requirements.
Each company implementing a message has different requirements. Making fields required forces specific data to be sent. When that data is not required by a company, that company is forced to send either blank or irrelevant data. OpenTravel believes it is a more effective to have optional fields than to force trading partners to exchange data that is not needed.
The OpenTravel Best Practices Guidelines defines guidelines for all of OpenTravel's XML data assets. Specifications released prior to version base 2001C may not follow the guidelines defined in this document. This document may be updated on a regular basis.
All message level schema files are "owned" by a work group (Transport, Hospitality, Architecture and Travel Integration). The work group that owns the message is the first place to get your question resolved (see below - "How do I know which work group a message belongs to?").
As a member of OpenTravel, you have access to the workgroup and
project team mailing lists. Sending a detailed message to the
appropriate mailing list is the first way to get an immediate
discussion started. To be added to a mailing list, contact the specification manager.
If your question is not addressed quickly or satisfactorily, you may contact the specification manager (non-member requests will be directed to the CEO).
Being able to discuss your issue within a work group may help you determine whether the schema does meet your requirements or confirm that the schema requires an update. If the schema requires an update, discuss with the group possible solutions to satisfy the requirements.
Most message file names begin with a pattern. The pattern includes Air, Hotel, or Veh (Vehicle). If a name does not include one of those prefixes, the message is managed by the Travel Integration Work Group or Data Content/Best Practices.
Members and non-members can use the OpenTravel Implementers Forum, which is moderated by OpenTravel specification experts and used by developers as a discussion board for schema and implementation questions.
Formal comments must be made using the comments input form and are officially accepted during comment review periods. If comments have been previously discussed with the work group or the Data Content/Best Practices (DC/BP) sub-committee, there is a better chance that they will be resolved exactly as submitted.
Code list additions should first be submitted to the work group via the appropriate mailing list. Once the work group has reviewed and approved the change, the request will be sent by either the chair of the work group or by the specification manager or chair of DC/BP for inclusion in the OpenTravel code list.