Public:2008A Projects
From wiki.opentravel.org
Contents |
[edit] 2008A Project Teams
Below is a summary of each project team and links for more detail.
[edit] Content Distribution
The scope of this project covers multiple areas that are not necessarily related. We will be looking at carrying more description information and better controlling the content.
- Content Distribution Models & Supporting OpenTravel Transactions
Members have expressed an interest in exploring the possibilities of a push pre-notification method that would allow hotels to inform content partners that new content was available—possibly at a more granular element level. This would allow the other party to pull the message when they are ready and will most likely involve the NotifRQ and NotifRS messages (to inform the receiving party that content is available and to inform the sending party that the receiving party is aware that there is updated content available). The receiver could then request the data via the pull version of the message (OTA_HotelDescriptiveInfoRQ) when they are ready to receive it. As a group, we will determine if this concept can be accommodated with comments or if a new schema is required.
- Onward Distribution Notification
Additionally of interest is a new message that would notify hotels when a content distribution partner has distributed content to another partner, including a timestamp and the destination partner ID.
- Content Formatting & Display Order
Enhanced content formatting and display ordering of repeating elements (such as restaurants, room types and amenities) through various comment attributes would greatly enhance distributed content presentation and is something the group would like to investigate. This will most likely be accommodated as comments to the existing schema.
For each topic mentioned above, we will create instances for these new or revised use cases for content distribution with the intent of publishing in the MUG. Additionally, many of these proposed initiatives will most likely be comments to the schema and a thorough review of all existing messages will be conducted.
[edit] Post Event Report Business Requirements Definition
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.
- Link to Post Event Report Project Team page
- Post Event Report Business Requirements Definition Project Proposal
[edit] Tour Schemas (Product Description, Product Search, Availability)
These Schemas focus on distribution of descriptive information regarding the tour. This will be enabled through the definition of a TourProductNotification message pair, enabling ‘pushing’ descriptions from a supplier to a distributor.
These Schemas focus on the query for information on tours matching selection criteria. This will be enabled through the definition of a TourProductSearch request, enabling ‘querying’ for tours by a distributor to supplier, or from distributor to distributor.
These Schemas focus on a check for the availability of a specific (single) departure of a specific (single) tour for a specific quantity of travelers, with response being details of the requested tour if available, or a summary of alternative tours if the requested tour is not available... This will be enabled through the definition of a TourAvailability request, enabling ‘checking’ by a distributor to supplier.
