...
Item | Presenter/Suggested by | Issue | Notes | |
---|---|---|---|---|
Meta | ||||
5 min | Opening | USEFUL Jira RESOURCE: CRs I have not accepted. | ||
Main Agenda | ||||
15 min | openEHR platform release management. | Currently we release at a Component level, e.g. RM 1.1.0, AM 2.2.0 etc. We don’t currently have a full ‘platform release’ mechanism. To take care of e.g. RM 1.1.0 needs at least BASE 1.0.4 or similar. NB: general idea of the components in openEHR was to be loosely coupled, and have limited version inter-dependency. |
| |
15 min | Specification lifecycle management | We don’t currently mark specs as Obsolete / deprecated etc, although we do have guidelines for this. | The old PDF specs probably should be taken offline? We can’t regenerate them, so can’t easily mark them as deprecated within the docs. When do we deprecate RM, AM etc specs? Probably all pre-1.0.2 RM should be deprecated. ACTION:
| |
15 min | JSON schema update | Working on 2 versions of schemas -
Generated various RM versions. Question on how XXX_REF classes are represented in JSON schema. Based on JSON schema errors/ issues, BMMs might have issues and/or Archie BMM → JSON-schema generator. | Sebastian Iancu what variant of JSON schema to support in OpenAPI, versus in back-end CDR? What level of JSON schema spec supported for (external) payload spec, by OpenAPI? Also - question of ‘relaxed’ mode schema. Could defined relaxed form of RM in SM, and make BMM of that - this would then be a source for JSON schema that an be referenced from OpenAPI. | |
30 min | REST API update |
| Progress:
Issues:
| |
Tips and Tricks | ||||
Hackers' Corner | ||||
Next SEC call | ||||
Outstanding topics: Agenda items: |
...