Inconsistencies and incompatibilities in types definitions

[vpusher]

Building automated tests and tools, we discovered a few inconsistencies between the OBUK website (markdown) specs (https://github.com/OpenBankingUK/read-write-api-docs-pub) and the OpenAPI specs. More and more systems and apps use this types as the source of truth for their implementation. It should be fixed in further releases to increase the robustness of specification and avoid incompatibilities and type errors, in order to allow and ease its adoption.

Missing Components/Names:

• OBCashBalance1 (Markdown) vs OBReadBalance1/Balance as [synthetic type] (OpenAPI)
• OBCashAccount5 (Markdown) vs OBAccount6/Account as [synthetic type] (OpenAPI)
• OBReadData (Markdown) vs OBReadConsentResponse1/Data as [synthetic type] (OpenAPI)
• OBCurrencyExchange5/InstructedAmount as OBActiveOrHistoricCurrencyAndAmount (Markdown) vs OBCurrencyExchange5/InstructedAmount as [synthetic type] (OpenAPI)

=> This is not an exhaustive list. There are other synthetic definitions that needs to be declared as component using dedicated type names

Incompatibilities:

• OBCashAccount5_0 (OpenAPI) vs OBCashAccount5_1 (OpenAPI)

  • Identification is referenced as component vs synthetic definition.

• OBActiveOrHistoricCurrencyAndAmount_8 (OpenAPI)

  • Has an extra SubType compared to others (is that a new type version ?)

Components duplication:

• OBActiveOrHistoricCurrencyAndAmount (11 times)
• IOBBranchAndFinancialInstitutionIdentification5 (2 times)
• IOBBranchAndFinancialInstitutionIdentification6 (3 times)
• OBCashAccount5 (2 times)
• OBCashAccount6 (2 times)
• OB_OtherCodeType1 (9 times)

The previous feedback only relates to read-write-api-specs OpenAPI definitons.
This is for sure incomplete and there might be other inconsistencies in others OpenAPI files.