Meeting Minutes - UnionInternationalCheminsdeFer/OSDM Wiki

2022-09-23 Meeting

Latest Version

  • at the moment there is no alignement on how to distribute bikes or luggage. 2 approaches are competing: bikes as passenger types ot bikes as ancillaries.

  • multiplicity in the link between offerparts & products: can we have collective offerparts (in pricing or ticketing) but where different passengers have different products

  • we also have to make sure we can support cases with multiple fulfillments (different TCNs) on the same fulfillment DOcument (the model does not seem to support it today


  • Changes: passengerSpecification for offer request and response and booking request -> passenger is created at booking step only.

Discussion ensues on whether variations could be allowed i the passenger party described in the offer request and the booking request. The consensus is that while it does not impact the API specs, we should give as implementation rule that the passenger party in the booking request has to be the same as in the offer.Should there be a modification, it is up to the provider actually hosting the product to perform the validation. Distribution systems will not do it.


  • rename comfortClass --> travelClass

Confirm with Clemens that change is reflected in

  • add type to ancillary (caveat: BIKE, LUGGAGE are passenger type)

Discussion: model lugagge / bike can be modeled either as passenger type or as ancillary. Both have pro and cons, the group aggrees that it should be handeled consistently --> needs more discussion

  • Discuss states

Driver I-62.

We currently have status at the booking level, however it might be sensible to have at the leaves of a booking as well:

    admission   <-- status?

If yes what does that mean for the overall state? We have to ensure consistency.

Same question applies to fulfillment.

No decision taken concerning booking, needs more analysis.


2022-09-16 Meeting


Challenging use case:

Trip: Basel - Chur - Brig - Blatten (bei Naters)

  • leg_1: optional reservation (flat world train)
  • leg_2: required reservation (touristic train)
  • leg_3: - (bus)

Reservation only scenarios

The Offer API may be approached in three distinct ways

  • User doesn't possess any reservations/admissions (or doesn't provide that information to OSDM), and is presented with offers for admissions, mandatory and optional reservations. Validation that admissions cover entire trip and all mandatory reservations are selected is applied.
  • Power user or distributor requests reservations only and optionally details travel class. OSDM provides an offer that covers 1 or more trip legs. The user may select 1 or more of these reservations in booking step. Mandatory reservations are not enforced in reservation-only scenario.
  • (API needs to be reviewed/designed) User specifies which admissions/passes/reservation does possess, OSDM offers admissions and reservations to complement the entire trip.


Remove addmissionSelection as if you book the offer then the admissions are being confirmed as well.

Show on-hold modelling:


2022-09-09 Meeting

  • walk trough of proposed changes


  • An offer needs to cover a whole trip or even a set of trips (return trip).


  • Review return trips and partial trips
  • trips-collection request or tripSeachrCriteria in the offer-collection request: How to handle meta stations with merits ids?
  • fix patch bookings
  • cart functionality

PATCH /bookings/{bookingId}/bookedOffers

GET /bookings/{bookingId}/bookedOffers

DELETE /bookings/{bookingId}/bookedOffers


2022-09-02 Meeting

  • Thoroughly review the changes (
    • CommonBookingPart / using inheritance?
    • NonTrip Offers broken

2022-08-26 Meeting

  • max length of a string, especiall of id strings
  • present v1.5-rc3
    • open question: Can we split Admission in AdmissionOffer and Admission etc.

Summary of discussion

Splitting ReservationOffers and Reservation is agreed on

Rename /offers/{offerId}/reservations/{reservationId}/ to /offers/{offerId}/reservationOffers/{reservationOfferId}*

Two flows

a. First get offers and then call available places (supported)

b. First pre-book offer and then call available places (not yet supported)

Modelling the two flows.

GET /availabilities/nearBy/?contexId={contextId}&contextType={offer ¦ booking}&resourceId={resourceId}&resourceType={reservation ¦ fare}

GET /availabilities/placeMap/?contextId={contextId}&contextType={offer ¦ booking}&resourceId={resourceId}&resourceType={reservation ¦ fare}

GET /availabilities/placeProperties/?contextId={contextId}&contextType={offer ¦ booking}&resourceId={resourceId}&resourceType={reservation ¦ fare}

  • Question by Turnit

    Provisional price vs confirmed price

    What is the provisional price in relation to the confirmed price? Is the idea that you can present both the price of the offer response and the price of the booking response in case of a price difference between offer and booking?

    Carrier vs Operator

    In the TimedLeg in the tripLeg, “operator” is used to identify a company, but on other places the word carrier is used. We believe “carrier” is more widely used in this context, but there might be some other good reason to use operator instead of carrier?


    As we see it is possible to apply a discount with a discount card or get an offer with a campaign code.

    But there are also needs to apply a discount on an offer that not really are a campaign and not are driven of a discount card.

    E.g. When issuing a replacement ticket for a delayed passenger it should be possible to issue a new ticket on a later train for free. But there might be other use cases where a passenger is entitled to a discount without having a card tor present.

    Applied promotion code and corporate code:

    appliedCorporateCodes and appliedPromocodes are available on booking level and the appliedpromocodes are also available in common offer part attributes, we think it should be on offer level.

    Suggestion, add appliedCorporateCodes to common offer part attributes.

    Is there a use case for keeping them on booking level?


    I the Post (and patch-) booking request you can add the “Purchaser”.

    It seems like the purchaser is a physical person only, we believe that it also could be a company, could a new element Company name be added in the Purchaser details?

    Creation time of booking

    The getBooking (and the future searchBooking-) response should contain the creation datetime (and timezone). The value should show when the booking (I guess pre-booking) was made.

    There are needs to make it visible to the user when the booking is done.

    “Booking on hold” – (“Stored” but not paid/fulfilled)

    This might be a bit bigger task.

    As we see it the time between pre-book and confirmation (TicketTimeLimit) is expected to be 20-30 minutes. When the booking is confirmed, an economical transaction has been created between the distributor and the allocation system.

    We have some use cases where it is expected that an agent should be able to make a booking “put it on hold” and maybe some days (or weeks-) later continue with to fulfillment.

    Is this anything that we have thought about in another way?

    State diagram (states of booking)

    In the booking diagram it seems to be two ways of going from pre-booked. When are the “confirmed” step used? or rather, when do we not go direct between pre-book and fulfilled?

    Currency object:

    When looking at the currency object one can believe that it is an array of currencies, but we believe that it is just examples, and only one may occur at the same time. Perhaps it would be better to just have “EUR” as example.

  • Revise Compliance

2022-08-19 Meeting

  • Changes to the v.1.5 specification

    • "You have to by n out of m ancillary/reservation" can now be expressed via Ancillary Relation / Reservation Relation

    Use cases exist in Sweden for breakfast, in Switzerland for touristic trains, and in Austria

  • Questions by öBB

    • tripId missing in POST offer-collections

      Add as third parameter to query offers.

    • How to deal with unsupported parameters (e.g. filters in place request) in requests.

      Return a response with a warning object indicating that the optional request parameter was ignored.

      Return an error "NOT SUPPORTED" if the parameter is required.

    • How to deal with places that do not have UIC code?

      Return the place id in an alternative namespace "x_swe:std:3452345" / "eva:stn:444444"`

      /places return alternativeIds if available

      inform Fabrice

2022-08-12 Meeting

  • Fulfillment Types and Fulfillment Media Types

Proposal from Ralf:

-- Remaining Fulfillment Types

Code Description
ETICKET Printable electronic ticket
DTICKET Fully digital ticket
CIT_PAPER Value paper
TICKETLESS No ticket, customer needs to provide means of identiy

-- Fulfillment Media Types referenced to Fulfillment Types

Code Applicable to Fulfillment Type Description
RCT2 CIT_PAPER RCT2 secure paper format (including compressed format)
RCCST CIT_PAPER Credit Card Size format
UIC_PDF ETICKET PDF according to UIC Standard
PDF_A4 ETICKET proprietary A4 pdf format
PKPASS DTICKET pkpass file format (‘wallet’)
ALLOCATOR_APP DTICKET mobile ticket in allocator specific format to be loaded into mobile app
NONE TICKETLESS no ticket, however the customer needs to informed that no ticket is needed
NONE DTICKET digital ticket has been referenced to chipcard number given in booking request (passenger.card.number)

2022-08-05 Meeting

  • How to do patches in UML?

  • tripSpecifications and requestedSections: how much of the trip needs to be spanned

    • For fares requestedSections is mandatory
    • We can not force a caller to pass in the complete trip.
    • For correct pricing in an international context we need to know the leg at least.
    • However it's useful to know the complete trips for other processes, such as operation planning.
  • reimbursemnt readded

    • not mandatory from a specification point of view, however if required by law needs to be implemented (E.g. Germany)
    • candidate for modularization
  • Fulfillment Types and Fulfillment Media Types

    Code Applicable to Fulfillment Type Description
    RCT2 CIT_PAPER RCT2 secure paper format (including compressed format)
    RCCST CIT_PAPER Credit Card Size format
    UIC_PDF ETICKET PDF according to UIC Standard
    PDF_A4 ETICKET proprietary A4 pdf format
    PKPASS DTICKET pkpass file format (‘wallet’)
    ALLOCATOR_APP DTICKET mobile ticket in allocator specific format to be loaded into mobile app
    TICKETLESS TICKETLESS no ticket, however the customer needs to informed that no ticket is needed

    What I’m wondering is what the exact meaning of the pass chip / pass reference is, and whether a fulfillment type is missing for “TICKETLESS”.

    • PASS_CHIP: The pass is loaded onto the chip. For example multi-journey tickets can be loaded on passes.
    • PASS_REFERENCE: Only a reference to the pass is loaded onto the chip. For example the SBB Half Fare Pass is reference by the SBB pass card.

    To do: final proposal by Ralf for next week.

  • Need for "Remise à disposition (RAD)" Supporting Carriers

    • SNCF, SJ, DB

    We need two steps for this process

    • refund done at the station (not the travel agency) calculating the refund fee and releasing booked places without accounting / payment
    • refund at the agency for the payment and to trigger the accounting

    We need to extend the refund state model:

    • Currently: PROPOSED --> CONFIRMED
    • New: PROPOSED --> ACCEPTED (booking is “refunded” but payment and accounting are pending, maybe there is a better word) --> CONFIRMED To go from PROPOSED to ACCEPTED we can use the existing PATCH with the new state.

2022-07-29 Meeting

  • accommodation sub types (cleanup and ÖBB comfort types)

    • add NEAR_WHEELCHAIR used to indicate places near the wheelchair when booked by an accompagning person.

    changed group names:

    • LEVEL --> DECK
  • reimboursement

    • to be discussed with andreas why generation failed (+ enum --> extensible and Notification Code)
  • change of seat - documentation

    • issues found by DB (Ralf)

       In TripOfferRequest the structure to limit the priced offer to a subset of the trip is placed in the TripSearchCriteria sub-structure, where it does not make any sense at all – when using TripSearchCriteria, there is no predefined trip which is being input, therefore the caller cannot specify for which legs/stations they want an offer. The requestedSection attribute should therefore be moved from TripSearchCriteria to TripSpecification. Comments need to be adopted as well.
      Symmetrical to the requestedSection, the provider should be able to specify that the offer given only covers part of the trip. This is “kind of” there, but there are multiple problems: The relevant structure (coveredLegIds) is present in “Offer” and “BookedOffer”, neither of which is returned by an offer search – the offer search returns an AbstractOffer. It think we have a problem with the inheritance structure between Offer, AbstractOffer and BookedOffer which we need to clean up.
      • patch will be provided for 1.5 (Ralf)
  • more fulfillment types for mobile tickets (Ralf)

    fulfillmentMediaType: - ALLOCATOR_APP content to be imported to an app of the allocator or bilaterally agreed

     securityElementType and format should become extensible enums and should be explaingd in the code list. 

2022-07-22 Meeting

remaining tasks in 1.5:

  • review of reimbourcement

  • request data are not in the patch request

  • reason should be an extensible enum

  • notification on the decision made should be added via webhook

  • change of seat

    • documentation missing (Roland)

for 1.6

  • combination of ancillaries (Andreas)

  • request a fulfillment again (after it is expired) or resend an fulfillment document by e-mail

  • I-61 needs more descriptions

  • I-59 to be splitt into separate topics

  • I-6 collect input for the topics (UIC Door2Door Project, NS bicyles,...)

2022-07-15 Meeting

  • OSDM API generated from UML model is available for review.
  • Clarify passenger ids in /offers and /bookings

Add id to PassengerSpecification and use it in the Offer flow (response and request)

Add optional gender to PassengerSpecification

Pass in PassengerSpecfication in /bookings and only create a Passenger in the Booking response.

  • New needs
    1. one-of the reservation offers needs to be booked
    2. one-of the ancillary offers in category needs be booked

Resolution for Reservation

Todo ASC

Resolution for Ancillary

 "ancillaryOptions": [ 
      "ancillaryReferenceGroup": "Meal",
      "minimalSelectableOption": 1,
      "maximalSelectableOption": 1,
      "selectableIds": [
      "ancillaryReferenceGroup": "Souvenir",
      "minimalSelectableOption": 0,
      "maximalSelectableOption": 3,
      "selectableIds": [
  • rename:
    • optionalsReservationIds --> reservationIds
    • optionalsAncillaryIds --> ancillaryIds

Rename is ok, we will also have to add all reservationIds

  • Use case optional place properties not respected --> need for message?
  • New improvments I-61, I-62, and I-63.

2022-07-08 Meeting

  • Small Issues in OSDM 1.5
    • Fix Fulfillment Patch Part
    • Applied CorporateCodes
    • getZones(): What is returned?
    • Improve documents

Voiding tickets needs an improvement

  • Functional Questions

    1. Let's say I need to travel between A and B two times next week. So, I need to buy 2 round-trip tickets (A <-> B).

      1. How should we handle round-trip tickets? I guess it's two separate offers - one for outbound and one for inbound. And if I have two of them then I'll end up with four offers.

        Some of our customers use "round-trip pricing", i.e. if you buy one round-trip instead of two one-way trips (separate trips for outbound and inbound) then you'll get a better price. How could that be handled?

      2. Multiple journeys in one booking vol 1 - let's take a case where I would like to buy two round-trip tickets. I couldn't find a way in OSDM to add additional offers to an existing booking. Should the offer searches be conducted for all the journeys first and then added all at once? If there is a race condition caused by capacity limitation then you may end up losing a place if you can't book it right away.

      3. Multiple journeys in one booking vol 2 - let's say I have managed somehow to add all my four offers to the booking and for some reason would like to remove one of them (because I just remembered that my dear friend John promised to give me a ride). Not sure how to achieve that in OSDM.

Round trips are supported (see: returnSearchParameters)

  1. It seems that the ancillary services that can be added as optional ones (not included in the trip offer) cannot be related to any of the legs. Let's take a case where I booked a multi-leg journey and I would like to add breakfast for leg 1 and lunch for leg 2. How to implement it in OSDM? (see ancillary-->commonOfferPartAttributes-->products-->legIds)

Needs two improvements

  1. Add/remove elements to a unconfirmed booking ("cart functionality")
  2. Add elements to a confirmed booking

2022-07-01 Meeting

Version 1.4.2 officially released.

  • Do we have the need for a mechanism to rely messages directly to passengers?

To do: find convincing use case in a new improvement.

2022-06-24 Meeting

From OSDM Meeting/Call 2022-06-23

  • Reminder: OSDM logo is approved and should be used along with domain to promote the specification

Publish logo on the website - Clemens

  • Announcement by DB: DB starts the implementation of OSDM with Phase 1 - Products (2022-2025) and Phase 2 - Fares (2025 and beyond). OSDM will publish the announcement in the community channels

To provide overview how the OSDM is used, please update Implementation Details with your projects, and possibly technology details if possible.

We need to create separate page for implementations, functional part coverage. Josef to start, consult Clemenc, Andreas on major functional parts, share in community.

Completion of PI-5

  • #278 Update of terminology: Clemenc, what is the status? We are waiting for contribution of Stefan Jugelt from ERA on 28.6.?

Replace Ticket Vendor to Retailer. Changes on the website only. Wording will be provided on Tuesday June 28.

  • #284 Revise embeds: Andreas - does it cover selected endpoint, or entire OSDM online?

ReDoc might not be updated, embed "TRIPS.PLACES" was already removed from 1.5.0 POST /trip-collection remove this embed check if conflicting changes happen or not

  • Pagination - issue, assignment, what is needed

rel was added, _links is missing yet See

Andreas to restore the old branch with former implementation.

still awaiting PR, could be contributed by anyone, not a blocker of I-32 CO2 report is implemented

  • I-46: Change of Seat after Booking: documentation is missing. Who will provide?

Roland will provide PR for documentation

Scope of PI-6

Epics, Enablers

  • Tooling and guidance for UML modelling of OSDM

Probably to first tasks to do, to spare the double work in UML and YAML Combine online and webhooks yamls

I-6 to be expanded; for the implementation, split to tasks covering required features

VAT exemption - elaborate with Swedish Team why it should be part of trip and request VAT exemption is also needed for Czechia, Slovakia VAT exemption vs VAT deduction Bileto to provide basic support for agencies paying turnover tax instead of VAT ? Margenbesteuerung / margin taxation

Additional parameters for booking search - e.g. possibility to search bookings by passenger details Booking search was part of 1.3, and removed later Search to be reintroduced Separate search by personal data (POST with body)

Ticket validation - outside of OSDM, please see UIC-IRS-90918-4 (ETCD)

Additional support for multi-ride/passes - support already included Clemens to check if the API provides information about remaining validity

Flag to indicate if passenger DoB is derived (by age) or provided (by passenger) Boolean indicator if the DoB is derived/provided vs separate property "pricing age" Additionally, how to have correct pricing age for return journeys (probably covered by terms of conditions only, not OSDM) PassengerSpecification and Passenger must be adjusted

To be discussed

  • Establish Certification Process (PATRIC group) -- Engineer requirements for the automatization of the certifcation process
  • Validation test set -- Review each others POSTMAN collections
  • Documentation update -- Clarify dealing with passengers without need for a ticket.
  • Security review --> 42Crunch
  • Model hardening with edge cases (non-happy flows)

2022-06-17 Meeting

  • Switched to Redoc


  • Fixed bug in PlaceRef concerning GeoPosition.


  • Fixed externalRef (#273)


  • Todo embed: fix, reduce or remove

add _links to PlaceRef, add rel to links and review embed.

  • Short demo of new version of sandbox

Thank you Tim, Roland and Sqills

  • Discussion

improve the documentation of POST fullfilments

add POST, GET, DELETE /documents

fulfillment.document -> fullfilmenetDocuments


Koffi prepares patch

2022-06-10 Meeting


  • Updates from SJ @stina

Must have features are in, PR soon avaible

PR merged

  • On placeRef: The specification is correct, however the UI of Swagger has problems in properly displaying inheritance.
    • Possible action: Use ReDoc instead.

Switch to Redoc

2022-06-03 Meeting


  • Fix externalRef

Patch will be provided

  • Adding an AbstractOffer -> Version 1.4.2

Decision: Release 1.4.2 is accepted

Transforming CommonOfferPart into inheritance in 1.5 - Decision: Model first and then check with group

Adhere to semantic versioning --> 1.5 becomes 2.0 - Decision: right thing to do, as we claim to support semantic versioning.

Design defined, needs a patch.

  • Points identified by Turnit:

    1. POST /trip-offer-collection response doesn't contain operator names. The names are needed for displaying in the sales applications. Would it be possible to add the names to the response?

    Add operaterName to DatedService (extension to OJP)

    1. POST /trip-offer-collection response doesn't contain the service/timetable attributes like WiFi, A/C, WC, etc. Hafas supports it and perhaps it would be a good idea to support it in OSDM as well?

    Needs to be added, check OJP how to do it.

    Facilities are part of the of attributes in DatedService

    Service Facilities in the code list needs cleaning

    1. In some cases the response of POST /trip-offer-collection may contain offers for hundreds of trips (e.g. airport shuttle that departs every 5 to 10 minutes) and there is a need for pagination. I read from swagger that _links[] can be used for pagination. Do you know if anyone has already implemented pagination this way?

    See OSDM Pagination.


  • Update pagination documentation to match actual specs

  • Add a "query" parameter allowing to steer pagination using a parameter (as opposed to just linking to the next/previous tripcollection id, for trips) => Nicolas Selleslagh to update

    1. The abstract property name needs to be changed to "summary" in 2.0 as it causes problems in code generators for languages where this is a reserved word. We should apply this to 1.4.2 as well, even though it is strictly a breaking change => to be documented as deviation from the semantic versioning guideline. Update: was actually supposedly changed already in 1.4.0. Is only still visible in callbacks => to be updated as well => Koffi to do the update

    2. Question from Sqills (Tim): Origin & destination in tripsearch criteria now only contain the discriminator objectType, and not the place where the ref can be placed

=> must be corrected before publishing

2022-05-20 Meeting

  • Refund of unused tickets

    Extended RefundOfferRequest

TODO align Overrule Codes between yml and documentation

  • Reseller Authentication

    Towards the remote inventories themselves most likely tokens will be used, but we have a chained situation in Sweden where the reseller connects to a GDS, who connects to an allocator, and then to the individual inventories. We would like to explore the possibility to transport identifying information in the header or the payload as a compliment to the token management.


2022-05-13 Meeting

  • We have moved to


  • Present OSDM modeled in UML (SBB)

Potential on the approach is big, we try it using lead modelers for a start.

  • Adding an abstract class to offer


  • Present Work on I-49 Change of Seat after Bookings (Sqills/Amadeus)

Tim will add analyses to page.

  • Ability to tag certain legs as being part of a train “alliance" (SJ)


image image

The experts continue working on finalizing a proposal

  • Address issues identified by Sqills

Using the UML model should help in keeping consistency.

2022-05-06 Meeting

  • OSDM EC Meeting
  • Designed I-47, I-51, I-52, I-54, I-55 and I-56.

2022-04-29 Meeting Minutes

No meeting due to many absences.

2022-04-22 Meeting Minutes

  • Present work on I-49 Payment information

    • solution is available in a separate branch extending the patch booking service
    • more payment types need to be added E_PAYMENT,..
    • alignment with I-48 needed
  • Present Work on I-48 Payment by Voucher

    • solution is available in a separate branch extending the patch booking service
    • alignment with I-49 needed
    • passengerIds shoule be optional (Gift-Voucher, Merchandising)
    • process description
    • vcode and issuer should be manadtory (also for Promos)
  • Present Work on I-58 Corporate Code

    • solution is available in a separate branch extending the patch booking service
    • companyRef to e renamed to issuer
    • beneficiary is a name
    • code and issuer should be mandatory
  • Train Facilities --> To be continued on the next meeting

    • facilities per class needed?
    • clean-up of codes, remove codes not used in MERITS --> Fabrice??
  • Ancillaries --> To be continued on the next meeting

    • use standard codes (urn and add a list in the code lists urn/uic/osdm/anc/... ) for "category" in the ancillaryOffer, not just a string
    • check for codes in NeTEX, MERITS/TAP-TSI-/Train Facilities
      • LUGGAGE
      • ...
      • generic types ON_BOARD_SERVICE, FOOD_ON_BOARD, ...
      • content from NetEX: NETEX SUPLEMENT_PRODUCT does not fit as it includes admissions and reservations and is lacking most other items. Useful to be reused is LUGGAGE, MEAL and WIFI which are in the Train Facility list already and additionally PARKING.
  • TODO add description on the urn for codes within an company defined list (currently used for stations) --> Nicolas

2022-04-15 Meeting Minutes

Good Friday, no meeting

2022-04-08 Meeting Minutes

  • Issues found by SBB's öV platform team; suggestions for Java/C# compatibility of openapi spec to be provided as PR

OSDM v.1.4.1 to be released until 2022-04-14

  • Next OSDM Meeting June 23th in Utrecht

Hybrid Meeting

  • Asc on vacation for two weeks

Clemens holds Meetings

2022-04-01 Meeting Minutes

  • Announcement by Turnit

  • Work on I-53 and other open tasks

Clemens has prepared a patch (

Added activation to fulfillment state diagram

  • Work on I-58


  • Company--> CompanyRef
  • CompanyCode --> CoporateCode
  • add list of CorporateCodes
  • Work on I-43

Review incorporated

2022-03-25 Meeting Minutes

Roland & Nicolas for the exchange part including place selection.

Clemens has prepared a patch (

2022-03-18 Meeting Minutes

  • Fix "PlaceRef" in V.1.4

keep oneOf semantic and remove topographicPlaceRef

  • Fix recursion on ViaStations

Remove routeand alternativeRoute for now, properly fix as soon as Clements is back.

2022-03-11 Meeting Minutes

  • Walk through of lastest changes to OSDM
    • Added cursor based pagination
    • Added proper HAL-JSON support
    • Renamed booker to purchaser

Accepted, remove cursor.

  • Address findings of Elisa for v.1.4.

Accepted, ASC will patch.

  • Address feedback by Nicolas on v.1.4.

PRs merged

2022-03-04 Meeting Minutes

  • Announcement by SJ and Samtrafiken to us OSDM for their new platforms.

Great news for the adoption of OSDM!

  • Walkthrough of latest changes to Version 1.4.
    • better support for real-time message
    • added booked offers


Idenified an issue with scrolling that needs to be addressed.

  • Add "Verwaltungscode" optionally to denote with company is really running the vehicle within a country.
    • E.g.: urn:uic:rics:1185:000044


from/until for temporal

start/end for spatial

bay vs quay vs terminal --> stopPointName

2022-02-25 Meeting Minutes

  • Walkthrough of recent changes to Version 1.4.
    • simplification on trip structure
    • tariff in product


  • Define necessary attributes of booker

Some systems do not support bookers. If a booker exist, only firstName and lastName are mandatory.

2022-02-18 Meeting Minutes

  • Information on Gap Analysis
  • Finalize Webhooks
  • Add feedback from öBB

2022-02-11 Meeting Minutes

  • Feedback on executive commitee 31/01/2022 (Andreas)
  • API versioning & production upgrade planning (Josef)

Best Practices

  • Add no major version to the path
  • Respect semantic versioning in OSDM spec versions
  • Optionally: support content negotiation
  • Support of the lastest and latest-1 versron at least
  • A version should be supported for at least to OSDM PIs, where a PI is ~4 months

operatorRef --> operatorRefs

legStop --> legBoard, legAlight...

2022-02-04 Meeting Minutes

  • Finalize web hook specification.
    • recommended receiver action
    • documentation: how it works, how to use it
    • Misalignment discovered between use case on trip events and expected logic . Leads to needed update in the booking design so it is possible to retrieve both saved trip and real-time version of
    • Trip event seem irrelevant in the context of OSDM. Only booking event which may consist in an updated on a related trip is relevant. Means that booking updates will be sent by RUs when a trip is modified even in case of open tickets.
    • BOOKING_CANCELLED EVENT is put in question:cancellation event should not be relevant: each party should proactively clean up when a cancellation occurs.

the trip (with a clear distinction) => Subject to a future fix

  • Clarify Question on Coach Layout:

  • Passengers without ticket: is it something we really want ? If so what are the exact requirements

  • Assess whether we are ready with next version

  • Review the TripSpecification: Is asking whether the latest updates on tripSpecifications have been committed & merged on the 1.4 branch.

2022-01-28 Meeting Minutes

  • Superfluous entry/exit points in fare

Not needed, Clemens will do a patch

  • Debriefing meeting with DG Move / Shift2Rail

Shift2Rail bases there work on OSDM modelling of distribution

Follow up: Define an Improvement to address functional gap in fare offline

  • OSDM for Buses, Josef prepares a deep dive

Todo: add slide

  • Review the TripSpecification

Patch looks good

But readd fare connection points

ASC prepares patch for client credential flow.

2022-01-21 Meeting Minutes

  • Concerning the length of vehicleNumber the size of H/H the field is restricted to 5,

    • I see two possibilities, either constrain vehicleNumber to max 5 or add a vehicleNumber.


    • Leave vehicleNumber and add a comment concerning the limitation of H/H. This reflects the commercial train number, no the operational train number
      • In Merits there's a field of 35 characters.
  • On trip: We see two scenarios

    1. The trip is created by the caller, i.e. the distributor

      To identify the requested trip, the relevant attributes per leg are:

      • origin and destination per scheduled legs (legBoard.stopPlace.stopPlaceRef)
      • vehicle number (legBoard.service.vehicleNumber or logBoard.service.lineNumeber respectively)
      • departure times (legBoard.stopPlace.serviceDeparture.timetabledTime) with a certain fuzziness of +/- 5 Minutes


      • Naming: TripSpecifcationand TripLegSpecification
      • Add lineNumber as alternative to vehicleNumber (especially for regional traffic)
      • Add array of vehicleNumber and lineNumber
      • A allocator should be flexible in matching departure times, however it's up to the system to define, if the trip matches.
    2. The trip is created by the receiver, i.e. the allocator

      To communicate the trip to the caller and the passenger, to following attributes need to be set:

      On Trip level:

      • tripId
      • duration
      • originand destination
      • origin (origin.stopPlace.stopPlaceRef and stopPlaceName) and destination (destination.origin.stopPlace.stopPlaceRef and stopPlaceName)
      • transfers
      • startTime
      • endTime
      • on TripLeg level:
        • legId
        • on TimedLeg
          • legBoard.stopPlace.stopPlaceRef and stopPlaceName and serviceArrival or serviceDeparture
          • legBoard.plannedQuay - SNCF only publishes this information shortly before
          • service.productionCategory.shortName and .name
          • vehicleNumbers xor lineNumbers
          • operatorRef
        • on TransferLeg: no changes
        • on ContinuousLeg: no changes

      Add to version to v.1.4

  • How to use vouchers which we give out in complaint management

    • Def. voucher: form of payment
    • Next Step: define improvements to properly plan and scope:
      1. Indicate form of payment of a booking as it has impact on after sale (real currency / virtual currency)
        • Koffi-Frédéric formulates improvement for v1.5
      2. Use "payment vouchers" <== ERA / TAP- TSI relevant
        • Clemens and Ralf formulates improvement for v1.5
      3. Redeem loyalty points
        • Address later
  • Reimboursement

    • Clemens has defined a version and will define a pull request
  • Claim Managements

    • a claim needs an id
    • train number --> vehicle number
    • remove iban --> accout number
  • Fix tripSearchCriteria

    • tripSearchCriteria.TripRequest for round trip with one leg
  • Operator change on a trip leg - how to deal with it?

    • Example: Chur to Brig

2022-01-14 Meeting Minutes

  • Address issues found in v.1.3.0:
    • Access-Token --> Authorization - accepted
    • trips.startTime | endTime | transfers optional, as redundant to same info in leg - rejected
    • publishedServiceName optional - rejected its Service Brand Code of Merits
    • tripLegIndices --> tripLegIds - alternative approch, use a tripRef, to be defined
    • tripKey: What is semantic? --> "externalRef" - accepted
    • passengerIds: add array - accepted
    • product.code: make mandatory - accepted
    • accommodationSubType: make mandatory
    • coveredTripLegIndexes --> coveredTripLegIndexes
    • add FEE as enum to requestedOfferParts - rejected, clarification in documentation that fees are returned as part of admissions or reservations if exsiting
  • Reimboursement of unused tickets (I-48)

2021-12-17 Meeting Minutes

  • Sandbox V1.3 released including updates to the POSTMAN selection

  • Requirements on an automated certification process

    • Certification can be done by two persons in one day.

    • Means to upload relevant information to certification group

      • information about credentials and URL
      • set of tests, including documentation
      • information on trains, products, fares, reduction cards, (seat map if needed)
    • Support different levels of certification

      • Mandatory, i.e. basic certification
      • Functional extensions to the the basic set
    • The party wanting be certified should be able to run the process py its own prior to the submitting it to the offical certification process.

    • Provide a means to show the results of the test run.

    • Tooling support

      • Test driver on the API level. AIM: functional correctness
      • Simple shop implementation interface that allows to validate replies of a given reply. AIM: semantically correctness
    • Optional: Measure of response time.

    • Provided by OSDM tech group to solution provider

      • OSDM API
      • Test variations needed
      • Supoort

2021-12-10 Metting Minutes

  • Finalizing I-41
  • Working on documentation

2021-12-03 Meeting Minutes

Discuss & address the encoding of names:

Split group

  • Group 1: Documentation
  • Group 2: Event Modelling

2021-11-26 Meeting Minutes

  1. Small demo on events in S3

Lessons learned:

  • Address security
  • Add subscription mechanism


  • Update specification to OpenApi 3.1 to benefit from web hooks
  • Model eventing (webhooks) in a different version
  1. Synchronization


  1. Finalize TCO change

PR merged

  1. Quality of current API

Crunch42 API Security Audit shows issues to address

2011-11-19 Meeting Minutes

Finalize exchange states.

  • for the (old) fulfillment there is no difference whether it has been refunded or exchanged: in both cases it is no longer valid
  • therefore, adding a state "exchanged" to the fulfillment adds no value but complexity
  • need to mention in the documentation that "refunded" also applies to the exchange process.

I-44 Booking Synchronisation Management

Message to distributor should contain

  • booking id
  • version of the booking (e.g. ETAG)
  • list of event types
  • need to define message format in JSON
  • With the ETAG and the booking id the distributor can filter out changes they caused themselves
  • for other changes, the distributor should retrieve the booking (or part thereof, depending on the event type)
  • notification on complaints - separate stream, put into I-39
    • Message structure would be similar:
      • complaint id
      • version of the complaint (e.g. ETAG)
      • list of event types (currently only one: COMPLAINT_DECIDED

Technical message flow

  • could use message queues or http/REST calls
    • http/REST has the advantage of not introducing new technology into OSDM: we will use a http/REST call
  • recipient has to confirm the receipt, once they confirmed the responsibility to process is on the recipient
    • on 5xx-Error, sender will retry, on 4xx-Error or 20x-Success, not retries by sender
    • on retries, sender should use exponential back-off (increasing timeout values)
  • callback URL should be configured into the technical configuration of the setup between provider and distributor
  • semantic effect of events discussed - for details see I-44 and I-39
  • Side issue: is the "booker" identical to the/a passenger? How do we know that?

I-45 Add responsible TCOs in the data from fare providers

  • Allocators need to know the list of possible TCOs for a particular fulfillment so they can mark the Tickets sent to eTCD accordingly
  • Information needs to come from fare providers (typically, TCO = carrier, but may be different in exceptional cases)
  • Information needs to be handled by allocator in their backend, but does not need to be forwarded to distributors
  • Model: Fare provider - allocator - any number of distributors
  • Should the model be: Fare provider - allocator - another allocator - distributor --> the second allocator acts as a distributor. First allocator has the responsibility to interface with eTCD, so only they need the information about the TCOs
  • has been modeled by Clemens, but is still in a separate branch

2021-11-12 Meeting Minutes

  • FYI: Finalized v1.3 and forward ported v1.3 to v1.4-rc
  • Add documentation reviews.
  • Discuss improvement by Amadeus

Approved by work group, should be scheduled for v1.5.

  • Organize lead for next Friday --> Ralf in charge.

Work on I-44, brain storming on event types.

2021-11-05 Meeting Minutes

  • Modelling and its impact on code generation
    • Review and fix issues

Fix Inlines and remove warnings from GET resources

  • Backward compatibility / Semantic versioning

  • Review Clemens' work

I-35, I-41, I-42 and I-43 are designed

  • Documentation to improve:

    • Search for Booking

    • Direct Booking

    • Master data resource

    • Claim Management

    • Non-Homogenous offers (Trenitalia case)

    • Asynchronous communication

    • Use of headers

    • Pagination

    • General review of documentation

      • Requirements, Business Capabilities, Models and Processes (Koffi, Nicolas, Andreas)
  • Update the getting started (Andreas)

  • Add search for bookings including pagination (Nicolas)


  • Adding stations, service brands/products, companies as name spaces

2021-10-29 Meeting Minutes

  • Added tracing headers (optional)
  • Overlapping codes cleaned
  • Release of V 1.3
  • Grooming of V 1.4
  • Discussion on Master Data


  • Synchronous Download (opt. with paging)
    • GET /masterdata/
  • Asynchronous
    • Queue

Versioning is needed, time to life indicates frequency needed to update

Handling of delta is difficult -> complete data set preferred

Decision: Add masterdata to the existing YAML file.

Interesting master data

  • OSDM offline package
  • reductions (code + description, Online: CardReference, Offline:)
  • stations (uic code, list of alternate names, coordinates, i18n, type, Online Place)
  • (products)
  • code lists

Master: provider

  • /masterdata/reductions
  • /masterdata/places
  • (/masterdata/products)

Master: UIC (excel list)

  • /masterdata/codes/cardType

2021-10-22 Meeting Minutes

  • Presentation of I-44 by ETT

PI should by part of PI 1.4

  • Clarification AccommodationSubType and PlaceProperty

Overlapping semantics -> Clemens does an overview of the concepts map

  • Finalize part 1 of groups

Booker added to the OSDM specification

  • Adding idempotency headers

Idempoteny headers to OSDM

Removed /bookings/search

2021-10-15 Meeting Minutes

  • Feedback of PSS on Scope

Scope accepted

  • Presentation of Billeto's test set.

Test set available on Github under /mocks

Added as I-42

  • Finalize groups

2021-10-08 Meeting Minutes

  • Add idempotency headers (@Nicolas)
  • Fix coachLayout semantics (@Clemens)
  • Finalize groups

2021-10-01 Meeting Minutes

Discuss #227

  • Decision: you can search an offer either by OfferSearchCriteria, a list of trips or a list of tripIds. In all cases you have to indicate which part of the trip should be priced. Both need to be passed in as a pair, e.g (trip, sub trip to price).

State of PI 3

  • Todo update documentation
  • Add vehicle filter (done)
  • Define when two trips are identically from the point of view of offer search

Discuss scope of PI-4 to be presented at PSS and PES (26.-27.11.)

2021-09-24 Meeting Minutes

What's next

  • remove version in links
  • add title in links
  • service arrival in timed leg intermediate stops cannot be mandatory (not specified when you cannot step out of the train

2021-09-17 Meeting Minutes

Review Enablers changes

URNs code, code list => domain:codelist:code => URN:STTN:UIC:880001 => go for it

  • update swagger
  • update code list page & documentation
  • can we allow default for both domain and code list so that only a code is actually needed and still call this a urn ? Would make it compatible with current data structure of the offline OSDM, which can be desirable at first. We could make this possible without "advertising" for it in the standard documentation

Idempotent post, patch and put

  • We do not want it on offers.
  • We may want it on post /booking (to be discussed cf re-usable offers etc).
  • We probably want that on most "change" operations (post subresource, puts and patches) => is mostly documentation **** raises up the concurrency and last resource version discussions (cf etags and use of if-match if-none-exists etc) => todo nicolas

Make embeds a parameter in POST as well?

  • No we decide to keep it where they are (at the moment there are never query parameters to our posts)

Add train number as a trip search criteria?

  • agreement to add it, to be understood as "returns connections that contain that train number" (as opposed to connections that only contains that train number.
  • check what OJP does about this
  • could later evolve to a list of trains but this implies further discussions on interpretation (is it and, or, x-or ?)

How to add reduction cards to the code list

  • Proposal: have a specific format in which the UIC and each provider's own list of codes would be specified. Each consumer can then build his own list based on the providers he is talking to (UIC+ the list of each provider) The format could be taken over from the OSDM offline format.

  • OK as a principle, the question is how to spread the codes

  • Since those are used in bi-lateral contexts, communicating applicable codes is up to the two parties

  • A publishing mechanism should be proposed (=> git (with osdm offline format), or OSDM platform ?) => should be discussed with OSDM offline so this part of the dataset can be made public => Clemens.

A lot of trips elements are mandatory, so it is an issue when we do not want to embed trips. A solution would be that for each resource you have at the "root" id, links, and an optional "content" element with the actual information, where mandatory flags are set => todo (Nicolas)

=> with the evolution via other changes, this issue is now resolved

Identifying vehicles

Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified comment Clemens: maybe we should wait for the transmodal alignement as this may be impacted.

  • the publishedService name can be used for line information
  • still need to change trainNumber into vehicleNumber (might be something else than a train)

2021-09-10 Meeting Minutes

  • Finally finalize OJP
  • Holiday ASC -> Nicolas leads the next two meetings.

2021-09-03 Meeting Minutes

  • Work on OJP patch

2021-08-27 Meeting Minutes

  • Demo of Biletto by Josef

First system to be live!

  • Introduction of Koffi-Frederic Konan

Welcome on board!

  • A Gentle Introduction to OSDM

Please review Gentle Introduction to OSDM

  • Organize merge of OJP OSDM patch

Workshop next week.

  • Work on I-30 Add the possibility for direct booking

Two aspects need to be taken into account:

  1. Speedup for experts
  2. Reduced look to book ratio

If offers are reusable a distributor needs to search for offers once, but then can cache these offers (equivalent passenger type (age category and reductions), same itinenary (same trains, same date), same product). The price can possibly change at booking time.

Especially if offers are not train bound / trip bound offers are reusable.

Todo: @Eliza adds a documentation and sequence diagram.

Special offers (e.g. "Bundeswehr", "Légion étrangère", "Vote in Italia") are modelled as promoCodes. Important: A allocator needs to check whether the requesting party is authorized to offer such special offers.

  • Open Topics
    • How to process a request for reaccommodations in case of missed connection and through ticket?
    • Do we want to provide the ability to have in a same bookings non-related offers, i.e. offers for different set of passengers and/or independent journeys?

Summer Holiday

2021-07-23 Meeting Minutes

  1. Small demo by SBB
  2. Work on patches & questions
  3. Finalizing support for promotions (I-29)


  • Token that reduces the price at pre-booking time OR
  • Token that reduces the price at shopping time OR
  • Token to receivce offers that are not available without it.

Voucher: Token that reduces the price at payment time

2021-07-16 Meeting Minutes

  1. Feedback


  1. Discuss OJP review results

Roland & Nicolas:

  • Make it less ambiguous
  • Remove oneOf/allOf/anyOf - preferably by using
  • Code list for station codes
  1. Resolve remaining open points

  2. Add support for promotions (I-29)

2021-07-09 Meeting Minutes

  1. Short update on UIC's PES meeting

Scope was formally endorsed by PES

  1. Initial landing of OJP patch


Please report issue on Github.

2021-07-02 Meeting Minutes

  1. Start using Kanban to address open issues

  2. Resolve points emerging from the Hackathon of Amadeus & Sqills:

  3. Work on I-4 and I-8

    • See Excel for comparison.

2021-06-25 Meeting Minutes

  1. Review of final Scope of PI-3 + planning

All the improvements have scoped for PI-3 have been discussed and initially analyzed.

2021-06-18 Meeting Minutes

  1. Presentation of Amadeus' Work

  2. Landing work on /place-informations and /trips

  3. Scoping PI-3

  4. Paragraph on authentication, please review:

  5. Overview: Language used by implementing parties.

2021-06-11 Meeting Minutes

  1. Presentation of Bileto's use of OSDM

Welcome on board and congratulations for the soon to be live implementation.

  1. Inconsistency in POST trip-offers-collection and POST non-trip-offers-collection

Fix inconsistency

  1. Q&A with OJP expert (Stefan de Konik).

  2. Multiple Segments

Describe two possibilities

  1. Merging legs of trips but offer two offers.
  2. Returning two trips
  1. Authentication Process

Conclusion: JWT token short lived and digitally signed (in production: <10 min) Don't reinvent in the wheel (OAuth2 compliance). Link to WASP API standard

2021-06-04 Meeting Minutes

  1. Authentication process feedback

See OSDM authentication mechanism

Discussion postponed as Nicolas and Roland were locked out.

  1. Update on OJP4OSDM

See Online OJP documentation.

Major difference: A Segment is called TripLeg which is abstract. Concrete implementations then are:

  • TimedLeg: passenger TRIP LEG with timetabled schedule
  • TransferLeg: A leg which links other leg of a trip where a transfers between different locations is required
  • ContinousLeg: A leg of a journey that is not bound to a timetable

Andreas provides a patch.

  1. Short presentation on OSDM in EA-Sparx. This modelling was done as a prerequisite for the OSDM alignment with Transmodel.

As part of the modelling a small inconsistency was discovered (NonTripOffer vs Offer).

Thus Offer will be replaced with TripBasedOffer and NonTripOffer with NonTripBasedOffer.

Andreas provides a patch.

  1. Add train number as a trip search criteria.

The need comes from the H2O converter. In H/H, a BookingRequest consists of date, and trainNumber.

The semantic for are single leg is clear: Only return trips where a vehicle with the given trainNumber (better vehicleNumber) is present. For a multi leg (segment) trip, the semantic is less obvious. Possible interpretation: only return trips where one of the legs is run by a vehicle with the vehicleNumber.

Home Work: Check whether your trip planning software supports such a semantic.

  1. Multiple Train Numbers per Segment

Several solutions have been discussed, see below.

Multiple Train Numbers

Home Work: Check whether you have a preference for any of the solutions.

  1. Scope of PI-3


  • For PI-3 concentrate supporting implementations with mocks/documentations/reviews and only add new features with high business need.

Home Work: Check with your teams what features are really needed.

2021-05-28 Meeting Minutes

  1. How to add reduction cards to the code list - OSDM Offline code list format (C.Gantert)

Clemens presented the structure used in the offline model For generic cards, there is no need to specify an issuer

  • For specific cards, their specificities would be exposed using the Offline format. The code to use in the API > is the id of the offline reduction card format, and starts with the issuer's RICS code
  • We decide to not consider the case where a specific card number is required to get a price, as it would > complexify the grammar too much.
  • An additional warning message could be foreseen to indicate a given card was not taken into account. => code change !
  • The international disabled reduction cards needs to be added in the UIC list, and when it is done we add it in our list. ** Clemens will add it.
  • File a new improvement for centralized source for codelists. for ex: predefined format in a csv file on gitHub or other (offline platform is an option as well, of sFTP, or ...) => Nicolas
  1. Vehicle (continued)

    Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified

    Comment Clemens: maybe we should wait for the transmodel alignment as this may be impacted.

    Our discussion is whether we should support line numbers => We should support both at least in the responses, at least one must always be provided.

2021-05-21 Meeting Minutes

1.Proposal to improve authentication (Nicolas)

Nicolas to share schemas and documentation reference with the group All parties check the provided material with respective security experts and come back to the group with conclusions

The agreement is that whichever way it goes, it does not impact the API specifications of the transactional messages. Specific questions are

  • Can we live with JWT that are not digitally signed by the client (and survive a security audit)?
  • Do we need the token factory on bob side as part of the standard, or can it be left to implementer / assigned to consumer (self-issued token mechanism cf open id connect)

=> homework to be checked by 2021-06-04

2.Finalize support for partial refund/exchange (I-3)

  • From an API operations standpoint, the most atomic element we can aftersale on is a ticket/TCN. Rationale
  • going lower makes the logic really complex
  • this is what is currently supported by web-oriented systems (some expert systems support manual processes to cover more granular operations) Consequences Refunding 1 pax on a multipax collective ticket is considered an exchange => the current API specs are covering this case (to be confirmed) some edge cases may cause an issue
  • if the train is sold out it will not be possible to refund one pax out a multipax ticket
  • the seats or price ranges of the original booking may not be available anymore

Note that supporting individual ticketing only certainly simplifies the case, but would seriously impact adoption of OSDM. Proposal : when just changing passengers set, only provide the passengers element in the ExchangeTripOfferRequest. (still supported by the syntax). Note this may still imply complex logic for the provider (ex: check if tariff conditions are still valid, whether seating options are still ok ex: wheelchair). Or the provider can implicitly refetch the original requests if they do not wish to support the party size change explicitly. => to be added in documentation => I-3 is hence closed.

3.Review home work

No additional feedback

4.How to add reduction cards to the code list

Proposal: have a specific format in which the UIC and each provider's own list of codes would be specififed. Each consumer can then build his own list based on the providers he is talking to (UIC+ the list of each provider) The format could be taken over from the OSDM offline format.

5.Passenger structure

  • Why do we have abstract & links as mandatory ? since we use it in requests as well, it does not make much sense (links in passengers for offer requests => ??)
  • we should add a list of passengers in the offer (and add it in the embed list). From an implementation standpoint. passengers in commonOfferPart then in reality are populated only with ids and links => todo (Nicolas)

6.Trips a lot of trips elements are mandatory, so it is an issue when we do not want to embed trips. A solution would be that for each resource you have at the "root" id, links, and an optional "content" element with the actual information, where mandatory flags are set => todo (Nicolas)

7.Code generation

Proposal is to encapsulate all inlined responses into response objects as otherwise code generation produces unnamed objects. => todo (Nicolas)


Shouldn't vehicles have always either a number or a line ? proposal is to have a comment indicating one should always be specified comment Clemens: maybe we should wait for the transmodal alignement as this may be impacted.

2021-05-07 Meeting Minutes

1.Reservation System Code in MERITS to find reservation system

  • Information on where to book the seat information can be part of the MERITs exchange format. More precise, it's the carrier.
  • Unfortunately it's not used by all providers of time table information.
  • Conclusion: Interesting information, should be made consistently available --> Talk to Merits expert (Fabrice)

2.Complete support for partial refund/exchange (I-3) based on the document by EU TravelTech

  • Definition: Upselling is an operation at booking time, exchanging which can include upgrading/downgrading is an operation at after sale date.
  • Re-Accommodation is interesting, however not in scope for the upcoming OSDM version 1.2. The idea is that the allocating system informs the distributor systems about events, e.g. disruption. Technically this could be done using webhooks for example (webhooks are part of OpenAPI 3.1) --> Add improvement for error and re-accommodation management.
  • Partial aftersale is the modification (refund or exchange) of a subset of the passengers and/or a subset of the segments of the booking. We discussed what should be the atomic entry point for exchange or refund: fulfillment (that has a 1:1 relation with TCN) vs pax/segment/item (item could even be an ancillary). We have not yet concluded whether it's acceptable to propose that: a) when all passengers and segments covered by a fulfillment have to be cancelled a refund can be triggered on the fulfillment b) when a reduction of the number in party or a change of the itinerary, then an exchange can be triggered on the fulfillment. If the proposal is acceptable, then the fulfillment can be the atomic entity for aftersale and it would be aligned with current grammar definition. If not, then the grammar would need update in order to define the type of aftersale allowed on a fullfillment.

3.Presentation of the OSDM Offline Platform by Hitrail

The platform will be ready for testing end of May.

2021-04-30 Meeting Minutes

  1. Recap meeting with OJP
    • What is our strategy?
    • Impact on current modelling?
    • How could an OSDM profile for OJP look like?
  • OJP light is a way forward, using its semantics makes sense.
  • OJP needs to be converted to JSON, work is ongoing at SBB.
  • In case of conflict we go with Transmodel (!)
  • Real time information as well as free floating legs are added value
  • Conclusions: "OJP on diet" and "Swimming in the stream" is the way forward
  • Clarify relationship between Hafas JSON and OJP
  • ASC will provide a patch and look into the OSDM profile thing
  1. Review Sqills token access point service
  • Service is ready, will be added to GitHub including a refresh endpoint asap
  • Sqills token will expire after 30 minutes
  1. State of mocking
    • State of work by öBB
  • Sets up a prototype to provide offer request.
    1. Number of trip collections to be returned: add attribute "number of response" to TripSearchCriteria and default it to 5.
    1. Parallel trains are already modeled as a list of numbers.
    1. Add segment of type walk using OJP style (Ralf, Klaus, Andreas and Peter).
    1. Clarify semantics of REAL_BOARDING_ALIGHTING --> OJP ("non commercial stops").
    1. Merits code list: Clemens add the Merits numbers.
    1. Add "bikeTransportNeeded" to TripSearchCriteria --> OJP
    1. Add additional information on vehicle ("facility code" of Merits) as options.
  • Review home work
  • Do home work
  1. Providing information where to shop to distributors

Quentin and Elisa reason about requirements

2021-04-23 Meeting Minutes

  1. Non functional requirements

Looping scenario is not responded. Rename "average" to "95% threshold". Find responsible numbers. Open: Whether these requirements are optional or mandatory

  1. Mock

öBB: creates an offer prototype, add EVA to codelist as "x-etensible-enum"

  1. Semantic of fareResourceLocation

Scenario: Paris - London by Eurostar and API at

Fare Level

Lookup Allocator to Fare Provider

  - carrier: Eurostar
  - serviceBrandCode: Eurostar

  - carrier: Eurostar
  - traindId: 293

  - Paris: Sqills
  - London: Sqills

  - offerType: TripOffer | NonTripOffer
  - interfaceType: OSDM
  - version: V1.2
  - system: Sqills

Allocator to other allocator - Open question

Offer Level

Distributor to allocator - Open question

  1. Design token factory endpoint

Home Work: Fill out Nicolas' mock Excel ("Scenario Variations").


  • Authentication is setup, review of service endpoint is next
  • Sandbox is ready
  • Document is ready and will be available soon

2021-04-16 Meeting Minutes

  1. Fix needed in the offline schema. There is no impact on the online schema

  2. Mock-up grid.

    Homework: everyone to look at the grid and place an X in own column to indicate willingness to represen t the variation in the scenario.

  3. Mock-up infrastructure

    Assumption is we can all address the already existing mocklab OSDM endpoint. If so, how can we collaborate in the same mocklab project ?

  4. Access to sqills endpoint ?

    Should be ready in about 3 weeks. At this point the endpoint will be shared. One point to address is how to set the authorization/ authentication part. for the rest, we do not go further than mentioning we follow OAuth2 proposal from Sqills: offer a fixed endpoint for the "token factory", part of the OSDM standard. This could act as a proxy that redirects to the provider's actual token factory. Standardize the way to get the token, not its content (such as validity period) Point for an upcoming agenda: design of the standardized enpoint.

  5. Yaml improvement

    Try to follow more RFC-standards Prev Next standard links urn for enumarated values Nicolas to write proper improvements or it so it can be assessed and prioritized

  6. I-18 review

    EP: we may need more than one tag in the booking request in case a provider proposes several segments with different through-ticket agreements This logic/situation needs to be toroughly documented

Question from Quentin: should we make post tikcet idempotent ? Nicolas: do we want to have idempotent POST ? At first sight No... but to be discussed further

2020-04-09 Meeting Minutes

  1. Finally finalize I-18
  2. Continue to discuss on Mocks 2a. Conceptual ideas (by Nicolas) 2b. Presentation of Sqill's approach 2c. Short presentation of MockLab


(1): Patch has landed


(2b): Access to all members of the group, Sqills will add a new service for authentication. Breaking changes are still possible. Best-effort at most for up-time. Information on trips, trains et al. will be presented to the group.


2020-03-26 Meeting Minutes

  1. Short update of OSDM Executive Meeting
  2. Review home work
  3. Finalize I-18
  4. Initial discussion on mocks with a
    • Presentation of live mock (by Roland)


(1): We need some tooling support to automatically test all the scenarios

(2): Discussion

  • We have to define what the number means (max time, 95% of time)
  • Find a balance between what is challenging and what is achievable
  • Add non-functional requirements for distributors
  • Will be part of version 1.2

(3): New encoding needed to tag to express reimboursement of offers.

(4): Highly interesting, big respect to the Sqill's team!

2020-03-19 Meeting Minutes

  1. Finalize I-7
  2. Start work on I-18
  3. Feedback on mock scenarios

2020-03-12 Meeting Minutes

  1. Short update on OSDM meeting, especially the mocking topic
  2. Short review of compliance section
  3. Finalize I-16
  4. Work on I-28

(1): Nicolas:

  • Shift to work on assets, that help to implement. For example, work on mocks.
  • Define and vary scenarios

(2): Decision: /trips and /products are mandatory

(3): Modelling is done, just needs some documentation

(4): Needs numericAvailability to be added to the offer and documentation

  • Improvement needed on reservations and fares resources.
  • Home Work: Think on scenarios.

2020-03-05 Meeting Minutes

  1. I-16 Add support to sell non-journey based products (passes) => Review changes Changes applied are exactly those discussed last week + a few naming changes for clarity
  • Still need to add the new fulfillment types in the appropriate code lists (if any)
  • Still need to update the card types list in the appropriate code lists (if any)
  1. I-28 Add support to query availabilities
  • Maintain segregation between layout info and availability information
  • We discussed whether querying availability information would be more relevant to do based on "inventory class", but in the end fall back to the current model, where availability calls are functions on offerparts within the offer
  • These calls are indirectly per segment ODs (via the offer and reservation id)
  1. I-7 Add full support for PRMs
  • Requirements introduced by David S.
  • We see three levels
    • Being able to file the request to ABT
    • Being able to handle unhappy flow
    • Investigate possibilities for pro-active information on chances of success of the booking
  • Next session David & Clemens will make a more detailed presentation on the business flow
  • Access to leaflet documentation to be checked for the work group members

2020-02-26 Meeting Minutes

  1. Update:

    • V1.1 is tagged and released
    • For I-18 and I-7 we have clarified the requirements.
  2. Finalize design of I-16

  3. Start design of I-28

  4. Homework: Please review:


  • Define NonTripOfferSearch criteria:

    • Add freetext
    • Identify students by generic student card, similarly a generic card for military personnel, ...
    • remove isReservation, serviceClassIds
  • Improve NonTripoffer

    • Add PassChip and PassReference to availableFulfillmentTypes
  • Transform CardReference.type to an array, x-extensible value and CHIP-CARD

  • Add optional address to PassengerDetail

  • Rename street_nr to street

  • Improve RefundOfferRequest:

    • add refundDate with default now. Date in the future is valid for partial refund of passes only.
  • Decision: No support exchange operations on passes

(3) Split availabilities of fares and availabilities of places

  • Limit availabilities to one day.
  • Improve OfferSearchCriteria:

2021-02-17 Meeting Minutes

  1. Release V1.1, final review

    • Review by öBB (ok)
    • OfferPart (ok)
    • feeAmount(ok)
    • boolean: true, false or undefined? (ok)
  2. Design I-16:


(1): Needs some alignement

  • nearby-Request: "coach" and "place" shoud be mandatory? (ok)
  • in the booking request "placeSelections[]/placeSelection{}/referencePlace{} and placeSelections[]/placeSelection{}/selectedCoach{}/..." the attributes should also be named "coach" and "place" as in the corresponding "nearby" Request (ok)
  • do we also need a test booking request for particularPlaces?
  • in the swagger the text at the attribute preferences and preferencesBundle (place-map, nearby, available-preferences) should be changed from "Place preferences (see code list PLacePreferences) the customer wants to have" to "Place preferences (see code list ReservationPreferences) the customer wants to have"

2021-02-12 Meeting Minutes

  1. Overview of scope of PI-2
  2. Add joint error codes by Klaus.
  3. Introduction to the following PIs:


(2): Add 409 on all POST/PUT/PATCH operations

2021-02-05 Meeting Minutes

  1. Fix seat reservation, so that Version 1.1 has the same functionality than Version 1.0. Merge patch by Clemens
  2. Merge I-1 patch by Eliza.
  3. Add Relationship-Offer-Offerpart-Product-and-Fare to the standard.
  4. Homework: Review updates on exchange documentation.


  • (1): Turn POST operations into GET operations by splitting into three operations /available-preferences, /seat-map and /nearby.
  • (1): ==> Rework needed, but feature is in for V1.1. Thanks Clemens!
  • (2): Remove offerClusters as it is redundant to coveredSegmentIndexes.
  • (2): A combinationTag on offer does not provide additional value --> not added. Combination of offers is controlled on product level.
  • (2): Rework of /trip-offer-collection
  • (2): Remodel tripId to tripHash (remove uuid type)
  • (2): Collection of segments in trip search
  • (2): New Boolean flag afterSaleByDistributorsOnly on BookingRequest.selectedOffers.selectedOfferIds structure
  • (2): Combination criteria needs to be respected in after-sale processes (basically partial-refund on one part leads to exchange of the other part).
  • (2): ==> Rework needed, but feature is in for V1.1. Thanks Eliza!

2021-01-28 Meeting Minutes

  1. Finalize I-2 Support for stateless offers booking processes

    • Patch by Nicolas merged, thank you Nicolas!
    • Documentation updated
  2. Discuss I-1-Enable-combination-rules-between-offers


  • (1): Merge landed, however some seat reservation is broken
  • (1): Joint view on seat reservation to be planned PI-3
  • (2): Tag concept is valuable and thus should be added
  • (2): Offers until the virtual border point between different allocators: possible to express on the API level.

2021-01-21 Meeting Minutes

  1. Add requiredInformation grammar as part of the standard.
  2. Discuss: I-2 Support for stateless offers booking processes
  3. Change cardinality OfferPart to Product to 1..n or even 1..2. --> Document reason why 0..2 is necessary (included reservation or ancillary do not have a product).
  4. Homework: Review Relationship-Offer-Offerpart-Product-and-Fare


  • (1): add ANY keyword to express "any customer"
  • (2): remove small grained resources
  • (4): included reservations do not need a product


  • (1): Grammar accepted for V1.1
  • (2): Add an improvement for direct booking

2021-01-15 Meeting Minutes


  1. Review updates on exchange documentation
  2. Homework: Review: I-2 Support for stateless offers booking processes
  3. Homework: Review requiredInformation grammar:


  • Exchange patch will be reworked and discussed

2021-01-07 Meeting Minutes


  1. Confluence moved to GitHub Wiki.

    Please sent me your GitHub accounts if you want to edit content.

  2. Discuss and merge two improvements:

  3. Discuss and merge other pull requests.

  4. Discuss adding Errors and Warnings as part of the standard.