/
Code List Management Take 3

Code List Management Take 3

Owned by Serm Kulvatunyou
Last updated: 2021-06-24
3 min read

History

Take 1 was pre-Score 2.0.

Take 2 was Score 2.0. In Take 2, Score implemented code list revisions just like other CCs.

Why Take 3

  • There is a proposal for code lists to be managed outside of OAGIS release.

  • Some reasons are

    • Code lists oftentimes do not change.

    • Users do not have to uplift code lists across OAGIS releases.

    • Code lists are managed outside of Score such as the case of Lockheed.

    • Standard code lists are also indeed managed by other SDOs.

    • Architecturally, code lists are tied to the BDT anyway - at least for OAGIS. So changes in code list can be reflected in the BDT revision - but the problem is we are thinking to do not provide BDT revision.

  • The fundamental concern is about the frequent release of OAGIS.

Proposal

  1. BDT references code list via GUID.

  2. Code list revision (for a given GUID) is limited to backwardly compatible changes. The following changes to a code list are considered backwardly compatible.

    1. Change name

    2. Change listID

    3. Change Agency → This should always display the latest publish revision of Agency ID Lists.

    4. Change version

    5. Change code list description & source

    6. Inactivate the code list

    7. Add code list value

    8. Change code list value description/meaning

    9. Inactivate code list value

  3. Generally, if a backwardly incompatible change is needed, a new code list must be created with a different GUID.

  4. Code list states. Keep consistent with CC & BIE. That is:

    1. Developer code list has four states WIP, Draft, Candidate and Published, consistent with developer CCs.

    2. End user code list has three states WIP, QA, and Production, consistent with BIE.

  5. Maintain the functionality that the end user code list may be derived (with extension and restriction) from a developer code list. Score needs to handle changes in the based developer code list. Fortunately, only backwardly compatible changes are allowed. This means Score has to propagate changes to the derived end user code list. The end user code list would reference the GUID and ID. We could implement a flag when an end user code list is not based on the latest version of the published developer code list and the user can propagate the change.

    1. How to deal with duplicate code list value in the change propagation. I think the user just needs to be made aware that the duplicate code list value will be replaced by the one from the based code list.

Agency ID List

Agency ID List would be managed the same way as code list - outside of CCs.

Code List references an Agency ID List in its Agency field. That would logically be a reference by GUID as well, i.e., a new revision of the Agency ID List would be automatically picked up.

The allowed backwardly compatible changes are the same as for the code list. The Agency field can be a self-reference (considering the Unit of Control). If it is a self-reference, we CANNOT display only the published revision here; otherwise, the first Agency ID List cannot have a value in this field. That means if an agency ID is deleted, a cascaded delete has to be done on this field. But if it is not a self-reference, the application should use only the latest published revision.

Other behaviors can be the same as those of the code list.

Canonical Expression

The application has to adapt a bit because these lists are not explicitly tagged with the release ID anymore. The application has to find developer lists that are referenced in CCs, and allow those to be assigned to a module.

The weird thing will be that expressing a canonical schema of a release at different times my yield different code list contents. I.e., the canonical expression becomes non-deterministic over time. Is that what we want? Another option would be to do not express code list in the canonical schema, all BDT tied to a code will simply be expressed as token.

UI Change

There will be a separate top-level menu called Value List which has two submenus, View/Edit Code List and View/Edit Agency ID List.

BIE Uplifting

Code list should be changed to matching by GUID. I.e., if the code list with the same GUID exists, use that one.

 

https://oagi.org/pages/connect-membership