Public:2008B Projects

From wiki.opentravel.org

Jump to: navigation, search

Contents

[edit] 2008B Project Teams

Below is a summary of each project team and links for more detail.

[edit] Creating An OpenTravel Data Dictionary (Architecture WG)

There are limitless ways implementers could (and have) extended and reused OpenTravel schemas. An OpenTravel Data Dictionary would facilitate greater and easier adoption:
1) By harmonizing the specifications by resolving conflicting definitions.
2) By sanitizing evolutionary dead ends in the design of messages that are either no longer useful or were never developed fully.
3) Creating reusable components that can be consumed by a RESTful framework.
4) Creating reusable components that can be deployed in other OpenTravel messages.
5) Blending specifications across multiple platforms in new (internal) messages.
6) Develop a ‘more’ tool friendly specification.

A Data Dictionary should also make it easier for the work groups:
1) To produce new messages as it should be easier to identify and reuse existing components in new ways.
2) To support the existing messages because they will be much simpler and changes will be applied consistently.

The existing message based content represents a tremendous amount of work that would be foolish for implementers to ignore, the Data Dictionary represents a logical spin off of that work.

To create a data dictionary it will be necessary to deconstruct the message set into its component parts, harmonize the definitions of competing components and rebuild the subsequent messages.

[edit] Namespace Usage In OpenTravel Schemas (Architecture WG)

Namespaces serve a basic function in XML; they allow users to unambiguously determine the meaning of an XML element (or attribute) when more than one with the same name may exist. This is very important when schemas from multiple sources are brought together which would otherwise require that one or other schema change to resolve the conflict. E.g. the SOAP layer has an Address element which would conflict with the equivalent Address element in the OpenTravel specifications.

The outcome of this philosophy is 2 practices.
1) Segregation of Data: between different specifications that use common terminology but with different definitions.
2) Separation of Versions: between different releases of the same specification that may have to co-exist.
The use of namespaces within the OpenTravel Schemas presents significant challenges since neither approach has been adopted.

The study will be limited to identifying the various common practices in the industry, what trends may be emerging or have emerged since the introduction of namespaces in the OpenTravel messages. The opportunity will be taken to review the history of the namespace policy in the OpenTravel Alliance and working through the implications of all the alternative options on the consumers, providers and integrators within the travel industry.

[edit] PCI-PII And Remediation Study (Architecture WG)

The Payment Card Industry (PCI) is on a mission to force owners of systems that process or store payment card information to tighten their security to prevent the theft and/or misuse of customer payment card information, especially after a major breach such as the TJX incident. The PCI has established a set of very specific and stringent requirements for the data security standards (DSS) which are being used by the major card brands as the basis for the assessment and certification of PCI compliance.

Likewise, governments are beginning to recognize the importance of protecting personal information and are considering legislation that requires the protection of PII.

Lastly, personal information that is not strictly PII, but that does have monetary value and can be exploited, such as loyalty membership information, will also be included within the scope of this study.

Messages based on Open Travel schemas can contain both types of information. The purpose of this study will be to determine the extent of usage of PCI data and PII, and make recommendations regarding protection, remediation, and best practices. Although out of scope of this study, end point storage of sensitive data either by design, as in database storage, or inadvertently, as in server message logs, is an important issue. This study will make note any best practices regarding such storage.

[edit] Content Distribution (Hospitality WG)

This is a continuation of the work that occurred in the 2008A cycle.

The maturity of the OpenTravel specifications for electronic distribution (availability, booking, etc.) has led to renewed interest in other areas, such as Content distribution which is the focus of this document. Content distribution is the delivery of any and all data associated to a property from a supplier (e.g.. Hotel Company) to a consumer (e.g. GDS).

Today, hotel descriptive content can be specified in detail via the HotelDescriptiveContent element that is used by the HotelDescriptiveContentNotifRQ/RS and HotelDescriptiveInfoRQ/RS messages to push or pull such information.

This project will continue to look at different aspects in order to improve and extend the descriptive information available to consumers. Our objective is to review the messages for particular functionality and submit comments as necessary and create PTPs for future work as needed.

This project, while championed by member companies focused on the hotel industry, is open to input and participation from member companies in other verticals. Content distribution is not a function that serves only the hotel industry; all travel suppliers and distributors have the need for improved methods of content distribution.

[edit] Post Event Report Business Requirements Definition (Hospitality WG)

The Post Event Report serves to communicate an event’s actual history compiled upon completion of an event. The completed report is used by downstream users such as facilities, the meeting professional and for data warehousing. The Post Event Report form communicates event criteria actually used while conducting an event ranging from meeting room setup needs, audiovisual needs, catering needs, safety and security needs among other meeting and event requirements.

It is our intent to develop a schema to define this new business requirement. Portions of the development will re-use some existing message set elements. The mapping will include the xpath to the appropriate element or attribute within a revised OTA message. If there is not an appropriate field within the message, then the mapping will be extended outside of these messages.

Due to the scope of this message, it is our intent to study and map all necessary elements and make appropriate recommendations for schema enhancements based on past OTA/APEX messages leading to the development of appropriate schema elements that are required by the APEX Post Event Report. It is anticipated that work will begin early in 2008A work cycle with a target of publishing in time for the 2008B release.

[edit] Insurance Replacement Fields For Car Rental (Transport WG)

An Insurance Rental is a rental where an insurance company is paying for an individuals rental because their car was in an accident or stolen. The Open Travel message would provide the ability to request, modify or retrieve these types of reservations with the proper information by adding additional elements to accommodate insurance rentals and providing this information back to the insurance companies.

To facilitate the above insurance rental information the following information needs to be added to the Open Travel car rental messages identified in Section 1 of this PTP:
claim number – a number that the rental will be assigned to.
policy number – Customers insurance policy number.
repair location – The actual location the customers personal car is being repaired.
company charged days – Number of days being charged to the primary method of payment.
split bill indicator – To indicate what part of the rental will be paid by the insurance company and the part that would be paid by the customer (multiple methods of payment).
make/model preferred – Used to request a specific model, either for preference or contractual agreement.
reason for hire – This would be used for management information so customer can see the reasons for hires.

[edit] Opt-In/Opt-Out For Airlines (Transport WG)

To include the ability to offer additional services and discount options to the air traveler at time of reservation and to properly display these options at various points of a booking process.

The scope of the message should permit not only additional services but discounts for services that the consumer may elect to waive or decline in return for a discount or other compensation.
Example of an additional service: Advanced Seat Selection $15.00.
Example of a service the customer may waive: Receive $.5.00 off of the fare for electing not to check luggage.

The message structure should be flexible enough to be associated with a specific fare or fare family so that its description can be applied as an attribute of a specific fare and convey enough basic information for suitable back end processing of various reservation systems.

The message structure should be generic enough to allow reservation platforms to use all or parts of the message as is required for their specific capabilities.
Example: The message should be structured atomically to expose enough information for a reservation system to compose and SSR for internal systems or to allow a vendor to orchestrate the message within their back end system from a proprietary created method or component.
Example of a possible element/attribute structure.

[edit] Dynamic Packaging (Travel Integration WG)

The purpose of this project team is to create XML messages that consist of a hotel, car, and/or air component in a single transaction between the supplier and a trading partner. Currently the only way to satisfy such a request is to send each message individually. This is not advantageous as component (air, hotel, car) prices are interdependent and sending separate messages makes it more difficult to determine how each package component relates to others.

A typical use would allow, for example, a supplier of air travel to provide any combination of air, hotel and car information in a single message (with pricing for each component) and send this message to a trading partner who in turn provides a package price to end consumers. Each component price is opaque to the end user and no single price is valid without the others. In effect, the supplier provides the trading partner with a set of wholesale prices. The trading partner is then free to (or contractually obligated to) mark up the cost and display a single package price to the end user.

There is a need for these messages as several members have developed internal solutions in the absence of an OpenTravel solution.

[edit] Profiles Update (Travel Integration WG)

Profile management is becoming increasingly important within most travel industry sectors, both to help provide better service to customers and clients, and also as a central tool to collect and harmonize data for marketing and performance analysis.

This project will enhance the current OTA Profile messages and extend the messages to handle advanced search. New schemas will be developed to handle merge operations.

The scope of this project is to enhance guest and account/corporate profiles. In addition to enhancing the data model (OTA_ProfileCreateRQ) the following operations will either be enhanced or added:
Profile Search – OTA_ReadRQ
Profile Merge – a new OTA_ProfileMergeRQ
Profile Multi Delete – OTA_DeleteRQ/RS

[edit] Guidelines for Mobile Integration

Harnessing the opportunity of the mobile web means different things to different people. This document seeks to categorise the practical opportunities, highlights the major differences between fixed line and mobile and recommends methods to integrate existing systems. This will not be limited to mobile internet, and may include SMS, etc. Work will be mindful of mobile carrier requirements and their recommendations. The project should include the following:

  • Defining the practical opportunities today
    • Transactional
      • Browse
      • Check availability and rates
      • Reserve
      • Call to book
      • Secure transactions
    • Added value services
      • Travel ‘concierge’
      • Mobile check in
      • Retail coupons
  • Highlight the differences between fixed and mobile internet
    • Environment
      • Device
      • Connectivity
      • User costs
  • Integration of existing systems
    • Considerations
    • Options
    • Web Services/API’s

Project Page: Mobile Device Project Page

Project Proposal: Study Mobile Integration Recommendation

Status: Architecture WG Review

Target Completion: 11/14/2008

Retrieved from "http://wiki.opentravel.org/index.php/Public:2008B_Projects"
Personal tools