Versions Compared

Version Old Version 4 New Version Current
Changes made by

Serm Kulvatunyou

Serm Kulvatunyou

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

History

Take 1 was pre-Score 2.0.

...

  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. Deprecate Inactivate the code list

    7. Add code list valueDeprecate

    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.

...

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.

...