Meeting 2, 3: Team 2 - Technical architecture

Scope

General brainstorm on the technical architecture of the API Specification. It can address some of the specificities identified here (e.g., readibility, consistency, etc.) or general ones (e.g., how to handle meta-data, what are the specs for the input, etc.)

How to contribute

Fill out this template and post it below:

• Specificity / problem to solve:
• How:
• If any, where it has been used before:

[edwinvandenbelt]

duplicate

[edwinvandenbelt]

duplicate

[edwinvandenbelt]

What to do with meta data?

[edwinvandenbelt]

How to set a structure, to facilitate extensibility?

[edwinvandenbelt]

I mean, a structure for the endpoints? Like 'perform an operation' ( input ) -> output. Is it possible to structure the different inputs and outputs? For instance, could the output (in most cases) be the modified booking/travel package?

[edwinvandenbelt]

for instance: if you want to cancel a booking:
POST /bookings/{id}/cancellation {body) -> a cancelled booking
(or OGC equivalent: POST /processes/cancel-booking/execution {body} -> a cancelled booking)

What I mean, should we try to make this a pattern, that can be repeated on all/most endpoints? That makes extending the API (other requests) very easy.

Should we give it a try?

[edwinvandenbelt]

How should we shape the process the 'user actions' (aka endpoints?).
Proposal: functional mapping:

• Look at each call in each API, and find the alternatives in the other APIs
• Find the corresponding Transmodel PI REQUEST
• Look at the 'inputs' and 'outputs'
• Per concept & attribute in the inputs (at least), what are the overlapping parts and what is unique?
• Map these to Transmodel as well
• Document the mapping

a functional call, like 'create a booking' (which would lead in OSDM terminology to 'POST /bookings') has an alternative in the TOMP-API: POST /processes/purchase-offers/execution, and I don't know (yet) the Transmodel PI Request (we can propose one?).
After this, we should map the attributes towards each other and relate to Transmodel concepts/attributes.

[edwinvandenbelt]

The first attempt can be found in the wiki process and the outcomes

[CGantert345]

The functional mapping might be a good way to proceed. However we need to improve the quality of the functional areas:

• there ara areas mixed which include incompatible topics (e.g. availability can not be a single functional area as availability of a seat on a train for reservation is entirely dicfferent from an availabilty to rent a car).
• the functional areas are sometimes process and sometimes objects on sale (e.g. search offers , ancillaries). These are not independent. We need them both in the list. but should somehow indicate the typoe of "functional area".
• the after sales area needs to be split. It is a common problem to underestimate after sales compared to the booking, but we need to split this into separate areas.
• The functional description is in many parts not correct (e.g. for OSDM Physical asset management, Trip execution / leg operations , ravel guarantees & redress), functional areas are reported to be missing which are actually included in the API.

The comparison of end point seems to be usefull as well, but the first draft includes a lot of errors and sometimes does not identify similar or equal end points (e.g. POST /availabilities/on-demand-services vs. GET /collections/assets/items)

The approach seems toi be usefull, but the quality of the content is far from being useable.

How can we improve quality and report or correct errors in a traceable way?

[bobvinke]

It seems we can use AI to make suggestions and propose a structure. However comparing should be done based on detailed understanding of the use case in each seperate model. It is only then that we can identify if the endpoint is redundant in both models, so they can be merged. This is manual work, were we need to listen carefully to each other.. There is no short cut to quality!

[edwinvandenbelt]

-ility	Description
Reliability	The system works correctly and consistently over time, without unexpected failures.
Availability	The system is up and accessible when users need it (e.g. 99.9% uptime = max ~8.7h downtime/year).
Scalability	The system can handle growing load (users, data, requests) without degradation.
Maintainability	The ease with which the system can be modified, fixed, or improved over time.
Testability	How easily you can verify that the system behaves correctly (unit tests, integration tests, etc.).
Observability	The ability to understand what's happening inside the system through logs, metrics, and traces.
Usability	How easy and intuitive the system is for end users to interact with.
Security	Protection against unauthorized access, data breaches, and malicious attacks.
Performance	How fast and efficiently the system responds under normal and peak conditions.
Portability	The ability to run the software in different environments (OS, cloud, on-prem).
Interoperability	How well the system integrates and communicates with other systems (e.g. via APIs, standards).
Deployability	How easily and safely new versions can be deployed to production (CI/CD, rollbacks).
Extensibility	How easily new features or modules can be added without breaking existing functionality.
Durability	Data is not lost — especially important for storage systems and event-driven architectures.
Auditability	The system keeps traceable records of who did what and when (important for compliance).

[edwinvandenbelt]

My 50cts: maintainability, usability, security, interoperability and extensibility are the ones we need to address.

[f-valenza]

i have a doubt for usability, since we don't address direct end users? as for maintainability, isn't it more at the implementation level? unless we mean that the design is easily modifiable or improved.
I would put performance, but again it is strongly linked to the implementation. Efficiency may be a better "ility". As an example, if I want to buy a single metro ticket for which I know the productId, I don't want to do a full booking process with many calls to the backend.

[edwinvandenbelt]

Frédéric, I think it is needed to enlist the 'ilities' (one discussion per ility), describe what we think is relevant from this perspective to EUDIT. I'll create one per ility.

[TOP-PHE]

One element is missing on my point of view : Predactibility. I need to know what I will receive in the response and the response should be consistent how ever I am calling.
To make thing simple if depending on the provider behind the behavior of the API is different, I will have to have a dedicated business logic developped in my application to manage it... Dedicated busieness logic = Cost.... If I have one standard that behave differently depending on the context... What is the added value compares to dedicated standard per mode of transportation ?
Or do we developpe an API dedicated to multimodal, and manging only trips involving different mode of transports and in this case "reducing" the functional scope to the minimum commun denominator ?

[fredriklj]

• Specificity / problem to solve: What endpoints do we need for starters?
• How: Decide what entities/roles/actors/functions will be involved in the initial modeling.

Suggestion: lets start simple with a minimal setup (MVP), we can always extend later if it is motivated

[edwinvandenbelt]

I think we need to cover (at least) all use cases in all the standards enlisted. If we're only delivering a subset, the standards who are not covered completely, will never 'jump over'. But we could start with a few candidate endpoints, to setup a process that we can repeat on all of the required functions.

[edwinvandenbelt]

Based on Ulfs presentation on the 10th, we need to discuss how we 'connect' to Transmodel. What are the options, what are the PROs and CONs of each?

[bobvinke]

Would it be enough to be able to map 1:1 to transmodel? so it is clear for each relevant Item with what Transmodel item is relates?

[edwinvandenbelt]

Unfortunally, it's almost never a 1:1 mapping to Transmodel. But we must map them anyhow. In the wiki the first attempts are made, but it requires a lot of validation.

[OlivierBigex]

Indeed. Corom tried a first mapping which is very perfectible (at least with OSDM)

[OlivierBigex]

@edwinvandenbelt , could you open en dedicated transverse discussion about the mapping which is currently on wiki ? common to Use cases and Architecture.

For example, mapping with OSDM:

• in French GT6, there is currently a huge discussion about the offer: is it SalesOfferPackage or CustomerPurchasePackage ? Because for us, the SOP is a generic offer which don't take into account the travel specification. The CPP does. and Transmodel doesn't seem to make a difference between a purchasable offer and a booked offer (both CPP).
• productTag is rather a SalesOfferPackageId (Product is too generic).
• an OSDM Booking isn't a CustomerPurchasePackage. A Booking (on Distributor side) is an higher level of aggregated purchased CustomerPurchasePackages. Moreover, an OSDM Booking isn't a FareContract. FareContract is rather an OSDM fulfilment.

==> Maybe Transmodel experts will explain to me that I don't understand anything about Transmodel, but I will love to have this discussion.

[edwinvandenbelt]

@OlivierBigex at your service! #34

[edwinvandenbelt]

Based on Ulfs presentation on the 10th, we need to discuss what the options are to modularise the interface. So, let's produce options and PROs/CONs.

[edwinvandenbelt]

For instance, seat assignment could be placed in the chauffered extensions (or in the train extension), e.g. ancillary assignment could live in the 'adjust' module (names are open to discussion, also the modules itself, it's just a draft).

[edwinvandenbelt]

Is this a way to go?

3 layers, where the bottom one will contain all generic concepts
the middle one will contain the generic functionality
the top one will contain role/mode specific concepts & functions.

[edwinvandenbelt]

This could be an implementation:

[edwinvandenbelt]

the general idea of the specific modules: it could contain

• a clear description of the possible flows for this mode, with
  • referenes to generic endpoints
  • custom endpoints
  • custom concepts

[OlivierBigex]

If a distributor wants to provide a multimodal trip (long-distance train + intercity bus + urban metro) to a retailer, how will that work with all these extensions ?

[edwinvandenbelt]

Ulf also proposed to use the 'TRAVEL PACKAGE' as a concept. For now, it is not used in any of the existing APIs, could this approach be helpful, would it make implementations easier?

[bobvinke]

Related to the Transmodel discussion above. If we recognize that different API's have different names for exactly the same defenition. we might need to choose. however changing all to the Transmodel terms might be a to large change in this phase of API development.

would it be possible to have the translation in the way we workout the API details. so we can always see. in EUDIT API name A is used, was B in TOMP and C in OMSA?

[edwinvandenbelt]

The first attempt can be found here

[TOP-PHE]

Thanks Edwin for the functionnal comparaison document.
I looked at it, and have some questions

1. Why you have Time/Table and schedules in the functions, as the Journey lanner is under the responsability of the distributor that should resolved on its side the journey. The EUDOT API will consume only OJP trips. Or did I missed a use cases requiring specifically time tables
2. Travel Guarantee and Redress : Why it is said not supported by OSDM, There are functionnalities in OSDM allowing the provider to inform about a disruption of the trip before the start of the journey and mechanism allowing the distributor to manage the redress.
   During the journey,
3. What do you mean by API/Discovery/Capability feature ? Discovery does NOT eliminate the need for prior knowledge of API behavior. "Different flows through the same API” often means different implementations and logic paths on the client side. The interrest of one unique API is to sell everything together the same way. I wonder if it is a mandatory feature.
4. Security: It was a debat on OSDM, and was closed in a pragmatic manner, there are existing standard managing generically the API security handcheck (Oauth for example). Should the API we are defining includes the security feature or should we segregade and be clear that it is the responsability of teh provider to use the most uptodate security standard ?
5. Payment: We did not put payment inside the API as payment are management aside the sales flow. The link between the payment and the sales flow is done by the distributor which valide the contract once it has secure the payment aside.
   If we do EUDIT is to support a multimodal distribution with the extreme use case with atrip wher at 5AM in the morning I will need to pick up a shared bike on the street close to my house, ride until the train station, jump in a train stopping at the airport where I will take a flight to New York. The Goal of EUDIT is to sell this all together in advance and secure that all this will work well on the D day. Paiement will be done when the booking of all the segment will be done potentially 6 months in advance and each provider signing the contract will guarantee that a ressource is available on the D day.... It could be paid by an account based apps... and maybe paid the day the bike will be used.
   It means shared bike that you guarantee that a bike will be available on the street close to your house and reserved for you, and you also guarantee that a free slot is available on the destination to park you bike.... How it will be unblocked for the user on the D day is not part of EUDIT I think. And if payment is really done the day you unlock the bike it is also outside EUDIT. We need to review and rediscuss the EUDIT use case on payment to well define the business expectation.

[OlivierBigex]

I started this discussion about booking and Travel Package: #34 (comment)

[bourdelin]

The TRAVEL PACKAGE proposal is a way to modeling what most of purchase API (not only on transport world but in Amazon or Ali BABA or any sale web site world) uses technically speaking : a blasket (called a "cart") with element/items added in, removed, modified, etc ... We have to manage that a TRANSPORT CUSTOMER can purchase more than one SALES OFFER PACKAGE in a single purchase.

[edwinvandenbelt]

During the meeting on the 10th, we also stumbled into the discussion about roles. Please stop this one, I guess we all have an idea how the existing APIs work and which parties/roles are on each side of the specification. The role-discussion must be finalised at the general meeting-level. For now, we stick close to what we have: a customer/traveller-facing side, a operator side (please provide a better name), and a validator side.

[TOP-PHE]

You have a use case in Rail and Air which must be taken in account in Business Travel :
Traveler (Business Traveler) / Purchaser (a Company) / a retailer ( Travel Agency) / A distributor (aggregating for the travel agency offers from different providers) / Providers.
You chose the mapping you want in terms on naming convention on those 5 roles as soon as we can identify clearly those 5 roles. And of course the same actor can play different roles. For example Trainline is a retailer (it has a B2C web site) but it is also a distributor, he is providing a service for Travel Agency to access to all Europe Rail content...

[edwinvandenbelt]

On the 10th there was also a slide starting the discussion about REST(full) vs RPC. I think we should work out a simple, equivalent endpoint, and enlist the PROs and CONs of each solution.

[edwinvandenbelt]

The last sentence is really strange. The use of OpenID Connect is required? That's pretty uncommon in machine-to-machine commication. Usually, the OAuth2 client credential flow is used for this. Optionally combined with private key JWT or mTLS.

[CGantert345]

Sales are not geospacial data. Using OGS deteriorates understandability of the API and creates additional costs in implemenating and maintenance without providing benefits.

[edwinvandenbelt]

Btw, I like that they are in favour of HATEOAS, although it has it's limitations.

And this one Stateless: each request from a client to a server must contain all the information necessary for the server to understand the request, without relying on any stored context on the server. This frees many interactions between the client and the server, but requires the client to locally retain all the data necessary for the correct execution of a request on the server. makes it really hard for us (and also conflicts with GDPR), if we need to exchange all information every time (this requires a service to validate the whole message: isn't the price changed, is the trip specification still consistent with it (you cannot say if the data is changes since the last time you've served it; you need to rely on the external party that they didn't modify anything). I don't know many APIs who are fully without a stored context on the server side.

The incorrect assumption here is that the client contains the 'single source of truth', while in our case, it is the server side that contains the information.

[edwinvandenbelt]

Sales are not geospacial data. Using OGS deteriorates understandability of the API and creates additional costs in implemenating and maintenance without providing benefits.

We need to make it as lean and mean as possible. If there's no benefit of adding geospacial data, we shouldn't.

[bourdelin]

My customer the most advanced on this subject and my company are agree to request our API to be only on the level 2 of Richardson Maturity Model (RMM). Depends what we are expecting. A compromise between effort, cost, usability, ...

[edwinvandenbelt]

Determine importance of Reliability : The system works correctly and consistently over time, without unexpected failures.
EUDIT relevance: none?

[edwinvandenbelt]

In my humble opinion, I'd say this is something that should be covered by SLAs, not in the specification (I even don't know how to address this)

[joachse]

I think we should include this. Concerns such as error handling, validation, idempotency, and rate limiting can be specified as part of the API specification and are important to ensure that the system works correctly and consistently. If not covered of any other *ility.

[edwinvandenbelt]

Error handling, yes I see that also in scope, but validation? How should we address that in an API description, Just like rate limiting..

[f-valenza]

The API will not define either what infrastructure will be needed. Reliability is very much dependant on what you put "behind" in the code, the server ressources, DB and so on. I agree to leave this on SLAs

[edwinvandenbelt]

Determine importance of Availability | The system is up and accessible when users need it (e.g. 99.9% uptime = max ~8.7h downtime/year).

[edwinvandenbelt]

In my humble opinion, I'd say this is something that should be covered by SLAs, not in the specification (I even don't know how to address this)

[joachse]

I think I agree. If I were to suggest the specification could include endpoints such as GET /ping or GET /health to allow for availability monitoring.

... but I'd say not so important.

[edwinvandenbelt]

Determine importance of Maintainability | The ease with which the system can be modified, fixed, or improved over time.
EUDIT relevance: none?

[bobvinke]

This might be more a Governance topic. If there is a need to change, we need to have a discussion how to solve. Then the impact needs to be assesed for current implementations.
The main question might be. Breaking change or just addition.

regarding governance we need a faster proces to handle issues and change requests than the formal CEN CENELEC proces, and it might be needed that non local standardisation members could take part. This however means that we need capacity to arrange this and need participation of relevant members of the comunity, to support this proces.

[edwinvandenbelt]

@bobvinke Partly agree. If we have a bad structure/modularization of the API, it will definitely impact the maintainability. It's relevant in both discussions.

[joachse]

I agree that splitting the specification into multiple files or modules, combined with a clear and consistent structure, would improve its maintainability over time.

Also a good versioning strategy could help improving it over time...?

Also agree with @bobvinke on handling issues and change requests is a governance topic.

[edwinvandenbelt]

isn't the versioning strategy also a governance topic?

[TOP-PHE]

isn't the versioning strategy also a governance topic?

I do agree, versionning is a governace strategy. I would say that usually people are using Version changes when there is a major change (breaking change) and Release when it is only an evolution, but a governance subject as EUDIT project scope is to deliver the version 1 of EUDIT. I guess we just need to agree on where the version is defined in our API.

[edwinvandenbelt]

Determine importance of Testability | How easily you can verify that the system behaves correctly (unit tests, integration tests, etc.).
EUDIT relevance: none?

[bobvinke]

At least for the most relevant use cases, it helps to unify implementation if those who implement all use the same test tooling and scripts. It asures the use case is implemented in the same way. Our experience is that it is easier to connect if a partie tested its implementation in the same way. This however might be also a subject for Governance.

[edwinvandenbelt]

Agree to this one Bob! But I could imagine that we can derive a 'default test' set from the API specification. It might be an additional delivery, which might even be valuable to understand the specification and it's behaviour

[bobvinke]

We might in later phase be able to use the OSDM testscripts as a starting point.

[edwinvandenbelt]

Determine importance of Observability | The ability to understand what's happening inside the system through logs, metrics, and traces.
EUDIT relevance: none?

[bobvinke]

Inside the system? We are creating an API. Where two parties connect. so there is no one system as such. For each implementation it helps to store these so you can troubleshoot, when issues occur.

[edwinvandenbelt]

Agree, this is implementation. Or ecosystem (to proof you have delivered a certain data set).

[CGantert345]

providing the W3C Trace Context in the API might be usefull

[edwinvandenbelt]

W3C Trace Context: we should have a look at this. What's the impact on the existing services you're going to call (do they need to add traces as well)?

[edwinvandenbelt]

Determine importance of Usability | How easy and intuitive the system is for end users to interact with.
EUDIT relevance: none?

[edwinvandenbelt]

This is one of the reasons why we start at what's working right now, instead of starting from the Transmodel side. It must be comprehensible,

[TOP-PHE]

I saw somewhere else in a discussion an exchange on usability with someone replying it is an API used beteween machines... while usability refers often to end user interaction with the computer.
We should clarify that usability means here anybody willing to understand the API its logic to implement it should not spent days in reading the specs, or having a dedivated training at least for someone who knows perfectly his business and wants to run it with this API.

[f-valenza]

I don't see anywhere mention that the API should be easily understandable for developers to implement (probably on both sides of it). The API should be quite straightfoward or similar enough to existing patterns. Maybe "usability" could be used to address this?

[CGantert345]

We have "Readability" in the Tech 'ilities'

[edwinvandenbelt]

Determine importance of Security | Protection against unauthorized access, data breaches, and malicious attacks.
EUDIT relevance: major, I guess. What are the options/requirements?

[edwinvandenbelt]

should we prescribe authentication patterns (OAuth2 - client credentials, mTLS, ... )

[TOP-PHE]

We will be always one train late. There are dedicated groups managing API security, we should rely on the, and just reference them and define the link we have , like a token allowing us to have a secured conversation. The mean to generate the token is out iof EUDIT scope for me.

[edwinvandenbelt]

Determine importance of Performance | How fast and efficiently the system responds under normal and peak conditions.
EUDIT relevance: is this implementation specific (SLAs)?

[edwinvandenbelt]

Imho: SLA

[edwinvandenbelt]

Determine importance of Portability | The ability to run the software in different environments (OS, cloud, on-prem).
EUDIT relevance: maybe none, maybe not specific to environments, but to programming languages?

[edwinvandenbelt]

In other words, should we validate the API by generating code using multiple code generators? This might become a very hard one.

[CGantert345]

Avoiding constructs that cause known problems on usual code generators would be helpfull.

[edwinvandenbelt]

From my experience, it is hard, I tried a lot of these generators, and sometimes they require exactly the opposite of each other, especially when implementing inheritance (oneOf with discriminator, allOf in the subclass, etc). From the top of my head: Kotlin and Spring boot generators required both another way of specifying it.

[CGantert345]

Yes, therfore we should limit our use of inheritance to cases where there is realy a benefit.

[joachse]

I very much agree with the discussion!

[edwinvandenbelt]

Determine importance of Interoperability | How well the system integrates and communicates with other systems (e.g. via APIs, standards).
EUDIT relevance: high, but we need to examen all options how to do this. First option: Transmodel-approach

[CGantert345]

We should start from existing proven implementations, TRANSMODEL is not helpfull on this topic.

[edwinvandenbelt]

depends on how we're going to apply it.
Option 1: adopt the wordings & structure of TM
PRO: CEN happy
CON: huge gap between the market specs, what to do with 'missing concepts'? And the structure in TM is very often unnecessary complex to use it in an operational context
Option 2: adopt wordings where applicable
Option 3: refer to equivalent concept(s) in TM, including the conditions (if available)

I like option 3. This approach allows also to add mappings to e.g. ERA, OJP (although, this connection should be a 1:1), DATEX-II, etc.

A small example:

offer:
      x-semantics:
        Transmodel:
          concepts:
          - SALES OFFER PACKAGE (SD Sales Offer Package MODEL)
          definition: A package to be sold as a whole, consisting of one or several FARE PRODUCTs materialised thanks to one or several TRAVEL DOCUMENTs.
          conditions:
          - 'Partial match: a travel offer presented to the customer; SALES OFFER PACKAGE is the Transmodel saleable bundle of FARE PRODUCTs'
      <and here the yaml spec of an offer>

asset:
      x-semantics:
        Transmodel:
          concepts:
          - VEHICLE (RC Vehicle MODEL)
          definition: A public transport vehicle used for carrying passengers.
          conditions:
          - 'Partial match: physical vehicle or transport asset; VEHICLE is the Transmodel public transport vehicle'
        ERA:
          concepts:
          - Vehicle
          definition: A specific vehicle or wagon able and allowed to operate over railway infrastructure.
          conditions:
          - 'Partial match: a physical mobility asset (vehicle) directly maps to ERA''s Vehicle class.'
        DATEX-II:
          concepts:
          - Vehicle
          - VehicleCharacteristics
          definition: 'Vehicle: a mechanically propelled conveyance. VehicleCharacteristics: physical and operational attributes of a vehicle including type, fuel, and load.'
          conditions:
          - 'Partial match: a TOMP asset (physical vehicle for a leg) aligns with DATEX-II Vehicle and its VehicleCharacteristics.'
        GBFS:
          concepts:
          - vehicle_status
          - vehicle_types
          definition: 'vehicle_status: real-time location and status of individual vehicles. vehicle_types: catalogue of vehicle types with form factor and propulsion.'
          conditions:
          - 'Exact match: a TOMP asset directly corresponds to a GBFS vehicle_status entry, typed by vehicle_types.'
      <and here the yaml spec of an asset>

[edwinvandenbelt]

Determine importance of Deployability | How easily and safely new versions can be deployed to production (CI/CD, rollbacks).
EUDIT relevance: none?

[CGantert345]

CI/CD is not part of the API. This is fully up to implementors.

[edwinvandenbelt]

Determine importance of Extensibility | How easily new features or modules can be added without breaking existing functionality.
EUDIT relevance: high. New use cases are popping up everywhere. It's an illusion to think that what we will produce will cover all use cases (in the near future)

[bobvinke]

This is a governance question. Lets at least make sure we do not create new use cases, where an existing use case could be used.

if existing usecases do not fit a new use case, a new one can be created respecting existing use cases.

If a breaking change is needed. this would at least be a reason to start the CEN Cenelec proces!

[edwinvandenbelt]

Determine importance of Durability | Data is not lost — especially important for storage systems and event-driven architectures.
EUDIT relevance: none?

[CGantert345]

Yes, but it depends on the data, Losing an offer is not an issue, loosing a confirmed booking is.

[edwinvandenbelt]

Agree, but how can we address this in the spec. Isn't it an implementation aspect only?

[TOP-PHE]

The API does not guarantee the content of an API server or an API consumer. The API is only the messager, to make it very simple it provides a structure to exchange content, but it does not guarantee the content... The only thing we can define in the spec is the fact that one data should be kept as reused in different moment in EUDIT and outside EUDIT (like the booking ID)

[edwinvandenbelt]

Determine importance of Auditability | The system keeps traceable records of who did what and when (important for compliance).
EUDIT relevance: none?

[bobvinke]

I would not suggest to make tracable all data on offers and how calculated. If a suspicion of failure of compliance arises, investigation can be don with the production tool it self on real data and local system investigation.

furthermore this standard is developed with experts from different background. Making it a FAIR standard by design.

[edwinvandenbelt]

Agree, but I had to put all the 'ilities' here, so we can enlist them in the requirements document :-)

[CGantert345]

This should be up to the implementors. Given usual look-2-book ratios of 1:1000 and probably 1:3000 in Future requirements on auditability of offers is out of scope due to costs.

[TOP-PHE]

On this ppint, at least in the API spec do we define the usage of correlation-ID and request-ID or is it so standard that it is not required. I am not expert enough to know, but at least a minimum info to help in auditability in production

[bobvinke]

ease of understanding could be an issue. For smaller stakeholders (manily Carriers?) the huge mass of options could give a perseption of being complex. We might also want to think about how to make it easier to understand.

Things might not be to complex, however getting parties at the minimal knowledge level to take part remains a challenge. As there is potentialy a large group of smaller parties dat would want to join in the use of the standard. We should think about ways to get these parties up to speed.

[Ulf9]

I think that many of the ilities has little to do with our actual task and may distract us. Yes involved systems needs to handle the ilities, but much of this is out of scope for defining an API. I strongly believe we should focus on making this API simple to use with an unambiguous and easy to grasp terminology. We should avoid adding artificial limitations in an early stage. In my mind there is a basic seller <-> purchaser dialogue that is more or less general and can largely be reused also in a multistage scenario involving one or more intermediate aggregators.

[TuThoThai]

@Ulf9 and @edwinvandenbelt, we have @skinkie now joining EUDIT work, especially Team 2, as a fellow member of TC278 WG3 and one of the main maintainers of both NeTEx & SIRI technical artefacts