Forge: What would the required output

[edwinvandenbelt]

A: a MVP specification
B: the first draft specification, both object model and process
C: the first draft specification, only merged requests and responses
D: a process how to merge & map to Transmodel
E: other, please specify

[TuThoThai]

In an ideal world, I would like to have: B.

[edwinvandenbelt]

Yes, agree. But what should it cover:

1. only the set of functions that are in ALL standards (which probably be offering, purchasing + ticket distribution and reimbursement)
2. 1 + functions that are common (in MOST standards)
3. 2 + ....

[Ulf9]

There are different needs and focus in different standards.

I therefore think we should design an API that allows a multi-stage process supporting the complex cases, but at the same time allows for skipping some intermediate steps ( and some pieces of information) in the simpler cases. But lets not start there. Lets first focus on understanding the information itself.

Maybe it would be helpful if we could first identify all atomic units of information needed to be transferred over the API, at any stage in the process, by any standard. And then identify direct equivalences on these atomic units across different standards.

Then, or in parallel, from that investigate if we can construct bigger building blocks out of those atomic units of information (where some attributes may be optional).

The max size of a building block should not exceed the division into different API-calls applied by the most fine-grained standard.

Then we can identify which groupings of multiple such building blocks seems natural.

Thus, later we can devise certain intermediate API-calls to support the needs of the most fine-grained standard while others can skip such intermediate steps and use API-calls that handles multiple building-blocks in the same API-call.

Generally lets think composition instead of inheritance when constructing the API.

So starting to first list all atomic units of information and from them build a collection of fine-grained building-blocks and then in a second step see which groupings/combinations of building blocks are relevant in a second step.

What exact requests and responses to support will, in a later stage, come more naturally after at least after having sorted at some level what information to support and the level of granularity required.

That said, I am all for an iterative process where we work to a certain degree at each step and then return in a second round and adjust as necessary.

[CGantert345]

I like this bottom up aproach. We should also investigate at which point of the process the atomic units are needed and for which purpose.

[edwinvandenbelt]

Hear hear. What is a 'atomic unit'? A concepts (schemas in OpenAPI)?

[CGantert345]

In the best case we will find a way to go forward:

F: a process to merge/combine the existing APIs to a new common API and a prove of the merge concept on a small part of the API, A reduced "C" could be a test case.

A: an MVP only shifts the difficulties to the future.
B: is too ambitious and requires to vahe a merge concept before
C: is still too ambituous for the whole set of use cases, but could be a first step to find a concept for merging
D: Transmodel is not an API, this leads nowhere

[edwinvandenbelt]

Regarding D: Transmodel has a base structure for request/response objects

[joachse]

E: Assuming both the BUC and the existing standards are used as input for the Forge

flowchart TD
    BUC[BUC] --> Forge[The Forge]
    Standards[Existing Standards] --> Forge
    Forge --> Draft[Draft Specification]

Loading

I would also want to look into a framework for evaluating that the BUCs are covered by the draft specification, or in what degree they are covered. This way we could also deliver a coverage report together with any draft specification.