oai / sig-travel Goto Github PK

This is the agenda for the OAI travel special interest group for Friday June 11th, 2021

• Overview - Cover the basics of how group operates.
  • Weekly Call (Google Meet Link) - We have call each Friday.
  • Github Repository - Repo to manage details.
    • Issues - Quick submission of bugs and feedback.
    • Discussions - Ongoing asynchronous discussions.
    • Projects - Used to manage actual work occurring.
  • Slack Channel - Real time ephemeral discussions.
• What is the purpose?
• What is the Domain Model?
• Which organizations should be involved?
• What existing OpenAPIs are there?
• Who else should be involved?
• What protocols and patterns are we defining?

The weekly call is meant to provide updates and drive asynchronous discussions and work -- add any other agenda items below.

Get our mission statement out there and a little background.

Included in this task is creating an example or pattern for others to follow. What else needs to be done to make this useful to all.

Write sample use case using Gherkin notation as a Card in a new Github project

Can or should the DEx tool adopt the use of overlays to the support of local languages in documentation. I'm leaving the description to that as part of the investigation would be if yes, what is the extent of usage.

As an example, we have a model for hospitality in Open Travel 2.0 and Luis has a model from his updated Opera product. Need to sort out how and who brings these models together.

Looking for someone to make a recommendation on JMESPath. Is it something worth a deeper dive into considering legacy travel shop functions that are heavily parameter based, particularly for legacy air.

Help #sig-travel better understand the gherkin format and the available tools that could be used to record user stories. Karate for example extends into test automation based on those stories.

This is the agenda for the OAI travel special interest group for Friday June 17th, 2021:

• Domain / Models
• OpenAPIs
• Organizations

The weekly call is meant to provide updates and drive asynchronous discussions and work -- add any other agenda items below.

Check out Google approach to gRPC, see link https://google.aip.dev/127
https://google.aip.dev/

So much of the API development in travel is putting GET/PUT atop existing SOAP or even older legacy functions. Maybe gRPC is a more consistent approach to calling legacy functions.

Do I need to be given some level of authority to manage the sig-travel group moving forward?

The team has stated the need to define the API behavior needs for interoperability between travel verticals such as hotel, air, car, rail, cruise, tours and so on. A hotel booking, for example, is a hotel booking no matter if requested by a traveler or an airline. An air booking is a an air booking if requested by a traveler or a rail operator to make a connection. Or are they?
The team quickly identified several issues around security.
A major issue is the handling of PII data and following GDPR and similar regulations. The use case could be a traveler contacts a hotel to make a reservation but also would like to add some tours and the air/rail booking to get there. The hotel operator has the credentials of the traveler and has the permission to use that PII data but must be careful in how to do a booking with another service provider on the travelers behalf. of course this happens to by a travel agent (multi bookings on behalf of the traveler) but I can say from experience there are already GDPR issues with what is done today. For example the "forget me" request largely does not work. The team also noted concerns over how we handle data level security. Who can see what in the bookings?
The need is to crate user stories that illustrate the security and PII issues.

The team has stated the need to define the API behavior needs for interoperability between travel verticals such as hotel, air, car, rail, cruise, tours and so on. A hotel booking, for example, is a hotel booking no matter if requested by a traveler or an airline. An air booking is a an air booking if requested by a traveler or a rail operator to make a connection. Or are they?
I will open a separate issue on intermodal and cross vertical transactions focused on security. The team quickly identified several issues there.
This issue is to explore the non security issues. The major issue I can see is a booking such as tour, hotel, rail, air implies all four parts have an implied relationship. There is a tour I want to take, I need to hotel close by, and I will use rail connecting to air to get there. That's still leaving out ground transportation or car rental. A traveler making all the bookings is on hook to deal with any changes. The service providers would be expected to sort out what happens when one service changes (ex: tour is canceled that day) and the rest must react. One could assume a client side app would be expected to do it all or is there a need at the API level to allow one service provider to communicate to another a change is needed? Given the growing requirements for trip level bundling this could be a hot topic.

This is the agenda for June 25th, 2021

• Domains
• Travel Pass
• Attribute Base Selling
• Workflows - Trips & Reservations

Background, see document .
A major issue for travel API such as booking workflows are the inconsistencies. Within sectors like hospitality and across sectors as well. Distributors and channels often hard code the workflow for each hotel chain or airline (rail ,,,,) and in some case for hotels down to the property level (PMS). We need a way to either dynamically discover the workflow or as part the API documentation the API provider sends it.
A later effort if the approach referenced is accepted, to update the DEx tooling to allow definition of the workflow as a facet and the complier create the artifacts as needed.

Will move them from the Open Travel library.

The SIG-Travel team has been leveraging Postman collections. There was a request to create a dedicated account to be the single source of truth for the SIG-Travel collection.

Get Steve Livezey to walk through the DEX modeling tool.

Team, please add more as you come across them.
https://devportal.atpco.net/docs/new-routehappy/new-routehappy/
https://devportal.atpco.net/docs/ndc/ndcx_messages/
https://www.atpco.net/routehappy

Leverage 'scripting' in Postman, an example can be seen [here(https://learning.postman.com/docs/writing-scripts/intro-to-scripts/)]

This is the agenda for July 9th, 2021

• Review the Good Health Pass Interoperability Blueprint
• Global Guidelines for Safe & Seamless Traveller Journey
• Digital Health Passes for Safe & Seamless Travel

Need to profile more - https://www.iata.org/en/programs/passenger/travel-pass/

One way to avoid API chaos is to use higher level tooling that supports, for example, model driven development (MDD). To be able to define a service at the domain level as how it acts of business objects in the library. Let tooling create the XSD and swagger documents. The result would be much more consistent API documentation and to some extent, behaviors.
This task is to look at the various options to come up a level, away from the schema, when defining APIs.

Links:
https://supermodel.io/#learn-more
https://opentravel.org/download-otm-tool/

Write up and present to the team a proposal on how we can record and manage travel user stories that illustrate API requirements and usage patterns. Intent is to publish the user stories along with reference architectures, reference implementations (APIs) and other material to show how to use the OAS to solve real world needs.

We need to make clear given the variety of people and organizations involved in sig-travel that anything posted in git is by definition open and available to anyone. While this is obvious to many it is not understood by all. We need to protect OAI as a mistake could cause legal issues. The intent is to show reasonable efforts to warn participants what precautions they need to take and OAI is not responsible for content posted.

See attached ppt for a brief description.
sig-travel OM.pptx