`TravelDocument` does not map to `offerIds`

[jorgenosberg]

The current spec does not allow for linking a single TravelDocument to the offer it actually covers. This makes it difficult for implementors to cover all the typical ticketing scenarios in MaaS, especially when related to and understood with #40 in mind:

• Package contains Offer A and Offer B for Traveller 1, service providers only offer documents for Offer A and Offer B individually
• Package contains Offer A and Offer B for Traveller 1, implementor can provide one aggregate TravelDocument that covers both offers
• Package contains Offer A and Offer B for Traveller 1 and Traveller 2, implementor can provide one TravelDocument that covers both travellers and both offers
• Package contains Offer A and Offer B for Traveller 1 and Traveller 2, service provides only offer group tickets per offer, meaning one TravelDocument to Traveller 1 and Traveller 2 for Offer A, and a separate TravelDocument for Traveller 1 and Traveller 2 for Offer B

travelDocument:
  x-tm: TRAVEL DOCUMENT
  type: object
  required:
    - startValidity
    - endValidity
    - travelDocumentType
    - travellerIds  # <--- Link to traveller(s)
    - offerIds      # <--- Link to offer(s)
  properties:
    travellerIds:
      type: array
      minItems: 1
      description: "References to the traveller(s) authorized by this document."
      items:
        $ref: "#/components/schemas/travellerReference"
    
    offerIds:      # <--- NEW FIELD
      type: array
      minItems: 1
      description: >-
        References to the offer(s) validated by this document. 
      items:
        $ref: "#/components/schemas/offerReference"
        
    # ... existing properties

[edwinvandenbelt]

The travel documents are delivered calling "GET /collections/travel-documents/items". It has as well a package as a leg as parameters. Is the traveler and offer derivable from the leg? Or do you have multiple travelers on one leg, with multiple tickets?

[jorgenosberg]

We support both group tickets where all travelers travel on the same ticket, but also group tickets where each traveler is issued a ticket (and possibly other docs related to each ticket, e.g. if it's available as PDF, as QR code, with a "daily animation" control image, a receipt or confirmation of purchase etc.).

E.g., in the typical scenario where a simple single-ticket has been purchased by a group of travelers, there will be 1 offer in 1 package, but 1 ticket per traveler, so we need some way to provide CRUD-like filtering for the clients so they can get the correct travel document(s) for the requested traveler(s)

[jorgenosberg]

@edwinvandenbelt This is also sort of related to #36 , as it deals with the fact that legs is an optional array and that we at Entur sell offers without legs. Simple products such as single and period tickets are sold as offers since they need configuration (zones, stopPlaces, duration, validity window etc.), but will never contain legs since they are not tied to any specific departures.