February 23, 2023 Technical Committee Meeting Note
Attendees
@Steve Conrad @Wes Brown @Valeria Tafoya @Satyajit Suri @PSRAMKUMAR @Aleksander Reitsakas @Martin Karner @Shukla, Ayush @Dominika Bieńkowska (Deactivated) @Ingmar Vali @Uwe Wahser @Nico Lueck @Kibuuka, Arnold @Meelis Zujev (Deactivated) @Nyoman Ribeka @Paweł Gesek
Agenda | Presenter | Duration | Discussion |
| @Esther Ogunjimi | 10 minutes | TECH-175: Technical Committee Action ItemsDone TECH-278: All BB Leads to confirm if data model has been defined for respective BBs.In Progress TECH-288: Review BB data core model in GithubIn Progress TECH-324: Create GitBook instance for wave 3 BBsDone
|
Status update Specification release v1.0
| @Steve Conrad @Esther Ogunjimi | 30 minutes | Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?)
Information Mediator BB
Next week
Messaging BB
Registration and Digital Registries BB
Registration BB should have more API points as this BB is considered to be a no code system, and there is no need to have APIs. However, the team will still hold on to the already defined APIs until there is a real use case where their workflow can be attached to the APIs, and decide the APIs that are needed. Steve - Do we need to make substantial changes to the BB specs (as the spec is structured as a no code platform)? This is to ensure other platforms can be compliant with the registration and registries specs. The language around the no code might be too specific. There is need to make decision to move forward - the approach to adopt for these BBs and other cases that many come up. Satay - There is currently one API specified for registration BB. From the test harness perspective, are we testing one API or what are we testing for registration BB? or are we testing local platforms ? or provide test harness for this? Based on the no code, low code for registration BB Wes - we should try to stay away from broad base functional changes to the specification. In general we should not be making substantial functional changes to the specs for the 1.0 publication. However, in the specific example of the registration BB, because we could be just removing functional content (the no-code and associated UI stuff) I think that that is worth doing for the 1.0 publication. Ramukumar - We stick to the capabilities considered. We need to come to the agreement that for v1.0 release, scope will not be added to the specs but clean up what is unclear or represented fully, rather than considering new features and new functionalities. Ingmar - Impact would be from the different other building blocks, not from the similar building blocks, comparing the digital registries or registration building block to similar products, the compliance will come from there. There is no need to have additional APIs as these additional APIs should come from other BBs that need the API from registration BB. More reason why registration BB is beginning of the user journey. Steve - who is responsible to make the foundational decisions about whether a no code or low code platform is acceptable for registration BB? This is to ensure the registration BB spec is not written such that it is only applicable to a single solution or platform because there are multiple existing products that could comply with the spec written. Wes - We need to make good decision to ensure the 1.0 release resonate with the broader community. Ingmar - the spec was built to fit similar products to have similar functionalities. The no code, low code application is a practical standard for the next generation of services, and that was what was built into the spec
Schedular BB
Consent BB
|
Definition and Testing of APIs | @PSRAMKUMAR | 25 minutes | Ramkumar - what is the API target coverage? what does it mean when we say APIs is tested for V1.0? Staya - for digital registries, there are 14 end point APIs, there are test case defined in gherkin for the 14 of them, and they have been tested and deployed in Circleci. There is standaridised template for every APIs on how to write the gherkin and cucumber script; which include sanity test cases, mock test cases etc. There are 12 endpoints APIs defined for ID BB. Three are tested and deployed completely while nine are still in the process of review. For payments, we have five tests API endpoints which are developed defined for voucher. G2P UC APIs are being finalised. Information mediator BB have five API endpoints, two have been tested and the rest is in the review process. Registration BB have one API. Consent and Workflow BB are being driven by the individual BBs themselves. Consent BB codes need to be merged. Workflow BB have five endpoints APIs defined with their test cases. Complete work is required for messaging BB as no API has been defined. Schedular BB has defined the standardised gherkin test cases and in progress for the rest of the APIs. The test cases need to be standardised based on the template. The priorities for March is to complete the test cases based on the standardised template and deploying them onto circle ci to qualify them for test harness capabilities. |
Definition of use-case examples for USCT | @Dominika Bieńkowska (Deactivated) | 25 minutes | API Testing - status across BBs Working on the registration BB steps and the flow diagram based on the postpartum UC. |
Retro | All |
|
Meeting Recording