Meeting Minutes - UnionInternationalCheminsdeFer/OSDM GitHub Wiki

Link to Team Meeting

2025-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.0.5+ 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