Skip to content

Meeting Minutes

Jump to bottom
Angelo edited this page Nov 21, 2024 · 1153 revisions

Link to Team Meeting

2025-01-10 - Focus: Fulfillments of Fares

Christmas and new Year Pause

2024-12-13

  • Clean-up
  • Get in Christmas mood

2024-12-06 - Focus: On Demand: Scoping

  • Experts:

    • Clemens
    • Ralf
    • trenitalia (tbd)
    • Andreas

  • Aims:

    • Make On-Demand Content (Bikes, Scooters,...) bookable via OSDM
    • Price indication, needs tracking (time, route)
    • Vehicle activation/deactivation flow
    • First consumption, settlement after
      • Delkredere risk - how to manage?
    • Billing (?)
      • Who is sending the bill
    • New after sales process
      • Incorrect tracking leads to incorrect bills leads to customer complaints...

2024-11-29 - Focus: Transportables

  1. Modification of OfferSearchCriteria (hard)
    • Modification on request parameters
  2. Returning of offers --> Modification on OfferPart structure (work)
    • impact analysis
  3. Booking of the modified offers (work)
    • impact analysis
  4. Addition of tariff border/border point location information
  5. Addition of the original price in the currency used by the fare provider inside the price object

2024-11-22

  • Pass Product - Best Practices & Potential Improvements
    • Martjin opens the discussion
    • Who is interested: SBB, Bileto, Sqills, turnit, DB, (öBB)

2024-11-15

  • Passenger Types & Transportables (30") (/)

    1. Classification and Modelling of Passengers & Ancillary Types (easy)
    2. Modification of OfferSearchCriteria (hard)
      • Modification on request parameters
    3. Returning of offers --> Modification on OfferPart structure (work)
      • impact analysis
    4. Booking of the modified offers (work)
      • impact analysis
    5. Impact after sales (hard)
    6. Impact on fares (work)

  • SBB: Coach Layout (30")

  • On Demand Services (30")

  • H2O Converter as part of TAP/TSI (10")

  • Open Issues (20")

  • Requestor (digestif)

2024-11-08

  • #382 Harmonization of transportable model could help inter-modality for Air-Rail (based on discussion between UIC and IATA).

Standalone call will be planned to split the issue, develop what is non-breaking, in OSDM 4.0, draft plan for stop having non-people passengers for transportables.

Doodle to plan the next meeting

  • #742 Resolved if regionalValiditySummary should be in abstract offer part - no, remove from reservations.

  • ERA Analysis of distribution rules in TAP, OSDM, and recent competition cases

DG COMP is concerned about Requestor field possibly discriminating distributors. eu travel tech can consult better description.

  • #747 Provide stubs of Fulfillments in asynchronous post fulfillment response

  • #739 When price is not available, there isn't unified behavior

  • #377 Josef to make PR

2024-10-31

  • #741 Fulfillment media type for bar code image fulfillment documents?

Denied. Already part of API.

#743 To be completed to provide capability to request offers by product codes from the catalogue.

  • #742 Add possibility to see validities for non-trip offers

Agreed. Josef will make PR

  • #410 Unified way to express included, required, optional reservations in offer. Ralf will make PR

  • #591 Ralf to update on discussed API limits

Question: "If Offer contains standalone reservation or ancillary, when it is booked, this part is added automatically".

  • #740 Ralf to lookup details on DB practice on upgrades

  • #744 How to provide retailer with information what fare/product was used to price the admission using its proprietary code list

2024-10-10

  • Presentation of results of Berlin Hackathon including next steps.

2024-10-03

  • Add more graphical items for coach layouts #710
  • Direction is missing for internals in GET /coach-layouts response #709

2024-09-27

  • State data loading for hackathon
  • SBB: add TripChangeRequest to OSDM #702

2024-09-20

2024-09-13

2024-09-06

  • Hackathon in Berlin

    • SBB, DB and ÖBB organizes a Dreiländerhack 2024 which takes place from 30th of September until 2nd of October in Berlin.

    • Aim: To build a OSDM web client that allows to connect to all existing OSDM sandboxes (benerail already officially provides its sandbox)

    • Setup support is provided by xatellite.space

    • The web client will be open sourced!

    • We invite everybody to join and motivate their Devs and Business Members to join.

    • Please contact Andreas or Patrick

  • OTST - How to identify offer types?

    • Generally vague definition
    • IRT (Integrated Train Ticket) --> offer part type ADMISSION with a RESERVATION. ADMISSION has an attribute with reservationIncluded
    • NRT (Non Reservation Train ticket) --> offer part type ADMISSION
    • TLT (Train Linked Ticket) --> product has an attribute isTrainBound

  • Authentication

    • Microsoft AD has specific requirements for format of custom JWT token scopes

  • Findings by benerail

    • issues reviewed and fixed

2024-08-30

  • Patrick Heuguet updated on OTST scenario development: Alten works on refund scenarios - now 4 different use cases of refund of IRT. Alten will now work on similar scenarios for NRT. Planning for further scenarios ahead.

  • Suggestions for scenarios should be written to issues of repo https://github.com/UnionInternationalCheminsdeFer/OSDM-testing

  • Documentation should emphasize that minor versions in single major version track are backward compatible. There is currently distrust in BC. (in technical principles #378 ). There are suspected breaking changes between 3.0, 3.2. Need to investigate.

  • #390 updated error handling recommended remove HTTP 405 and 406 in non breaking way, these statuses are handled by the general development framework.

  • GH issues are good way to maintain documentation of changes. Explore possibility of template for new issues, also guidance for new contributors so they provide means to contact them if they are not part of the technical group.

  • Friendly request to have your personal profiles at Github updated with name and company, so we know, who is requesting the changes in OSDM.

  • #671 feedback on migration to openapi 3.1 is needed. Please test the branch in pull request #620.

2024-08-23

  • #671 Feedback on OpenAPI Code generators

2024-08-16

  • #671 status on openApi version 3.1 with used generators

2024-08-09

  • Decision: Back port processes are agreed on

2024-08-02

  • Josef presented a draft of development process detailing current work with emphasize on back-porting and patches, to be discussed later https://github.com/UnionInternationalCheminsdeFer/OSDM/wiki/Development-Process

  • start version 4.0 with OpenAPI 3.0

  • openapi 3.1 changes are kept in separate branch for testing, will be rebased later

  • #372 Trenitalia needs on demand services: Clemens will start the first draft

  • Bileto found that Complains API is not implementable due to bugs in design. Looking for other parties to formulate change requirements for 4.0

  • #632 Some parties identify the clients only using JWT token data, other additionally by Requestor field (based on bilateral agreements). Making it optional in 4.0. Structure is not needed for ÖBB. Examples will be collected if structuring is needed.

  • #616 agreed as bug/needed improvement for code generation, fix for 3.4

  • #626 patch doc/openapi examples

  • #599 need to discuss with PKP IC

  • #603 proposal for change

2024-07-26

  • Version 4.0:

    • KK: OJP 2.0 is ready/under review: are there changes we have to consider in version 4.0?

      Known Changes PublishedLineName → PublishedServiceName OperatorRef muss in eine Gruppe gekapselt werden OperatorRefs Attribute/Text → Attribute/UserText TransferMode → TransferType Attribute/siri:xyzFacility müssen in Attribute/Facility gekapselt werden.

      SBB would like to add RefineTripRequest and ChangeTripRequest and StopPlaceRequest

  • Need for mailing list?

  • Merging patches to different versions - How do we do it?

  • OpenAPI 3.1.0 - Doest
    -Home Work: Double check whether this works with your Devs: https://github.com/UnionInternationalCheminsdeFer/OSDM/tree/migrate-to-openApi-3.1

  • Model 4.0 back log

2024-07-19

  • Version 4.0:

    • Home work: Inform your management about the reason why.

      • DB management accepted migration
      • Bileto is Ok for migration

    • Home work: What do you and your organization see in scope of 4.0

      • DB cleaning up the interface, make needed elements mandatory, make all arrays limited due to security, unify implementation options

      • FS add on demand services

      • Move to OpenApi from 3.0.3 to 3.10 (merge webhook description with rest of the API)

      • Bileto:

        • Offer search criteria for ancillaries,
        • split passengers between humans and transportables (similar to version 1)
        • solution for dogs, bikes etc..

      • ÖBB: Reservation Fares and Reservation cleanup

        • Review Product parameters to make it simplern (Combination rules?)
        • Eurail: Add a price in the product in case the product has a fixed price.

        Target Date February 2025

        TODO: create 4.0_draft as a copy of 3.4_draft (ready next week)

    • Home work: Decide whether we need a workshop (virtually or physically)

      • workshop: DB yes, Bileto: yes,
        • physical: DB difficult, Bileto: yes,

Version 3.4_draft is available to create changes

  • 3.4 needs to be made in parallel with 4.0.

2024-07-12

  • Introduction of Martijn van der Graaf of Eurail.
  • Introduction of Distribusion joins the working group.
  • Update concerning OSDM 4.0.
    • Go for version 4.0 has been given by OSDM executive committee. Expectation: Be finished by autumn 2024.
    • Rules for 4.0
      • Version 3.0 is still supported, there will be a 3.4+ branch
      • Versions <= 2.0 are being sun set
      • Home work: Inform your management about the reason why.
    • Why are we doing it:
      1. Remove unused features
      2. "The should be only way to do the same thing" - remove ambiguous flows/interpretations
      3. Remove deprecated attributes
    • Potential Scope
      • Complex Topics:
        • fee: Is fee a offer part?
        • fulfillment: some renaming, improve flow
        • ancillary vs passenger type for bikes ...
        • initiation of after sale (refund on TCN, exchange on booking)
        • define maximal length of data structure
        • update to latest OJP v. 2.0
      • Modularization / Extensions
        • Conceptually vs. technically
      • Home work: What do you and your organization see in scope of 4.0
    • Planning aspect
      • Continue work during summer.
      • Home work: Decide whether we need a workshop (virtually or physically) somewhere in September.
  • On Demand should be in next version
    • Hard to do correct without an actual customer --> Clarify need
  • User Guide for OSDM - What can be improved?
    • Linking of pages
    • More use cases
    • Search
    • Clarify roles
    • Concepts / User Guide / Reference Manual

2024-07-05

2024-06-28

  • Snälltåget is live using an OSDM API!
  • Fees
    • Different type fees exist, e.g. on product level, on booking level, etc.
    • Complex topic, needs a proper chapter of documentation, incl. examples
  • Topic: gross vs net fee
    • Better: Fee included in amount vs. Fee deducted from amount
    • Needs better documentation
  • Address #489 to finalize 3.3.0 | > moved to 3.4.0
  • Address refund on booking level
  • Workshop on certification testing

2024-06-21

  • Clarify definitions on roles and business capabilities (Thanks Odile for pointing out)
  • Address #593
  • Land new Problem definition in OSDM 3.3.
  • Discussion: OSDM 3.4 or 4.0
    • What would be the breaking changes
      • Complex Topics:
        • fee
        • fulfillment
        • ancillary vs passenger type for bikes ...
        • initiation of after sale (refund on TCN, exchange on booking)
        • ...

2024-06-14

  • OTST send out tender to find support to push the certification infrastructure.
    • Winner: Alten
    • Home work: identify scenarios of special
  • Present results of error special group (lead: Tim)
    • add a mandatory title
    • add problems additionally and deprecate warnings
    • update documentation, especially point out how problems or warning are modeled respectively
  • Remaining open tasks of 3.3

2024-06-07

  • Focus is on finalizing the OSDM 3.3. version

2024-05-31

2024-05-24

  • Address open issues
  • Discussion on groups --> next step is to compile the requirements as part of an improvement
  • Discussion on merchandising of seats. Next steps
    • input from air distribution to see how they model this distribution map
    • formulate an improvement

2024-05-17

  • Welcome new members from Wiremind, Irish Rail and Rail Europe!
  • Reach out to Polish rail to join discussion and clarify #543
  • Resolved #533, #489
  • Clarification on GET /availabilities/place-map
  • Clarification on GET /coach-layouts/

2024-05-10

2024-05-03

See issues.

2024-04-27

  • Proposal to make only low-risk yet breaking changes with 4.0 to set a sound basis for future evolutions (benerail/sqills)
  • Proposal to split the swagger in a few smaller blocks and separate non sales-process items from the core (masterdata, layouts, booking documents, complaint management...) (benerail/sqills)
  • Continue work on ancillary harmoinzation

2024-04-19

  • Best practice / experience of multi-inventory transaction handling (SJ)
  • Continue work on ancillary harmoinzation

2024-04-12

PR is accepted by group and merged. However we need to harmonize/clean up the accommodation sub type list.

  • proposal on language handling (#401)=> please review (benerail)

PR is accepted by group and merged. Thanks Nicolas!

  • Does it make sense to have the a list of refundOffers in the post response ? we would rather return only 1 refund offer, potentially referring multiple fulfillments (benerail)

a valid usecase would be to get multiple refundoffer, all covering all the fulfillments but f ex different fulfillment methods associated with different amounts (f ex vouchers => 100% and cash =>90%). so we keep the array but all offers have to cover the complete scope of fulfillments we still enforce the rule to have only one ongoing refundoffer at a time. one onging refund offer needs to be confirmed or deleted before another one can be added

  • We are repeating complete fulfillments in refundoffers (also in get booking responses) which does not seem very efficient => should be changed like we did with products (benerail)

it is another breaking change=> a good change to propose for v.4 we could however alreayd return the fulfillmentRef so we can already prepare the change

  • valid until in refund is mandatory but does not make sense on a confirmed refundOffer (benerail)
    • can be filled with confirmed on value
  • Should we still get something for get /booking where everything has been cancelled/refunded ? (benerail)
    • Still get the booking
    • We could introduce a flag indicating whether we only want to see active bookings or also cancelled ones
  • What is now the ancillary offer/booking process ? (benerail)
    • to be put on the agenda of a future meeting

2024-04-05

  • proposal on languages handling is ready for discussion (benerail) => https://github.com/UnionInternationalCheminsdeFer/OSDM/issues/401 (to be discussed next week)
  • Issue 488: clarification will be done by Andreas (done already)
  • Issue 490: Josef to propose flow authentication (Backend-to-Frontend), will provide branch with documentation (proposal in 1-2 weeks)
  • Issue 491: Ralf proposed flow for authentication (Machine-to-Machine), will provide branch with documentation (approved)
  • #361: new meeting will be planned to complete the error handling proposal
  • #402 check if documentation need an update on fulfillment process (see last comments)
  • #437 needs PR
  • #448 needs to find mime types for wallets, PR
  • #449 needs PR
  • #362 needs PR
  • #494 Usual cases to be described to design more detailed webhook event. Odile will check how IATA NDC handles that.

2024-03-22

  • Issue 489: need to think about possible solutions
  • Issue 488: clarification will be done by Andreas (done already)
  • Issue 490: Josef to propose flow authentication (Backend-to-Frontend), will provide branch with documentation (proposal in 1-2 weeks)
  • Issue 491: Ralf proposed flow for authentication (Machine-to-Machine), will provide branch with documentation (approved)

2024-03-15

2024-03-08

2024-03-01

  • Quick update on demo
    • Partially successful, still doubts whether completely neutral to all parties
    • We will receive a list of technical question, which we will address
  • Finalize work on language handling
    • Nicolas will provide a patch
  • Address issues identified by DB
    • Ralf will provide patches

2024-02-23

  • OSDM 3.2 has been shipped

  • up to 10:00: discussion on how to model ancillaries

    Grande plan to address the topic

    1. Structure the notion of ancillaries (--> Airline Taxonomy)

    2. How to request ancillaries?

    3. How to represent ancillaries in an offer?

  • short update on preparation of demo

    Preparation with samtrafiken on February, 28th to GD Move

  • open issues

  • if time allows: introduce language handling (benerail) => https://github.com/UnionInternationalCheminsdeFer/OSDM/issues/401

2024-02-16

  • Update of OSDM EC
    • Concerns of skeptics:
      1. Journey tied to railway so they favor their inventory
      2. Combination of offers only possible by railway only
      3. Booking can not be cancelled
      4. Lack of support for multi-modality
    • Need for a visual client by a distributor to convince skeptics:
      • Turnit is checking whether they can provide a client (3.0.3)
      • Sqills is checking whether they can provide a client (3.0.3)

        Patrick Heuget coordinates effort to provide a convincing demo on February, 28th

  • Finalizing Version 3.2.
    • Andreas will provide PDF
    • Compile a release note passed on Items in GitHub
  • Adding Bileto and Bene sandboxes to page.
  • Scoping Version 3.3.
  • Check on OSDM's implementation details

2024-02-09

  • Update of UIC Meeting in Rome.
  • Life Cycle of Major Versions, including sun setting of versions < Version 3.*
    • As a group we decide to no longer work on specifications < Version 3.*, bug fixes only.
    • Legally we can not force parties to upgrade, that needs to be defined bi-lateral
  • Address SBB issue (#465)

    Patch defined for v. 3.2

  • Address Issues (#437) and (#446)
  • Home Work: Please update supported/planned version of OSDM implementations Implementation Details

2024-02-02

  • Bundle 3.2 release

2024-01-26

  • (Tunit) ReductionCardType (appliedReductionCardTypes) doesn't hold information of cardNumber and cardType #420
  • (Tunit) ReturnSearchParameters in tripSpecification is missing #434
  • (Tunit) Possibility to display saving/reduction amounts for all types of reductions in an offer and booking #419

2024-01-19

  • State of Certification Process
  • Experience feedback on average response time in non functional specifications (Benerail/Nicolas S) -- Outcome: rephrase the non functional documentation to clarify, that --- it is not mandatory, rather guidelines --- should be considered for specific condition: 1 passenger 1 segment, own inventory, neglecting network latency, ...
  • Who should be in the purchaser entity (mentioned as mandatory) ? (Benerail/Nicolas S) -- expectation: would be the "most end-customer" actor of the story, not the distributor, not the agent, not the agent employee, rather the person sitting in front of him. -- it would be a company in case of a corporate booking for example (b2b booking site etc)
  • partial offers & clustering logic => which are the parties intending to use it ? and how (making sure there is still alignment there) ? (Benerail/Nicolas S)

2024-01-12

2024-01-05

OSDM Wiki

Links

Clone this wiki locally