| Author | Marc Johnson |
|---|---|
| Status |
| Awaiting Feedback | |
| Feedback Requested | 2020-08-10 |
|---|---|
| Deadline for Feedback | |
| Summary of Decision | |
| Decision Maker(s) | |
| Date Decided |
Context
FOLIO primarily has two ways to represent the choice of a value values from a set in back end APIs: enumerations and reference records (there are some exceptions, including unconstrained strings and hard coded sets).
...
Below is a comparison of how the characteristics affect this (and related behaviour) behaviour.
| Situation | Enumeration | Reference Records |
|---|---|---|
| When importing a MARC file, how does data import know the correct source to use? | Has to be hardcoded based upon the dependent interface version | Needs to be identified during the process (and might not exist) |
When creating a record, how does the reference UI know the correct source to use? | Has to be hardcoded based upon the dependent interface version | Needs to be identified during the process (and might not exist) |
| When presenting the search options, how does the reference UI know what source values can be used? | Has to be hardcoded based upon the dependent interface version | Can be fetched via the API entirely at runtime |
| How does the reference UI know whether an holdings record is editable | Sources that are editable have to be hardcoded based upon the dependent interface version | Clients need a way of identifying which source are editable |
| How can a tenant add a new source? | They cannot, sources can only be added for all implementations via the interface | Via the API (or possible a settings page in the reference UI) |
| If a new source is added, how does the system know if holdings with that source are editable? | As the list is fixed, is decided during development | Clients need a way of identifying which source are editable |
Impact of the characteristics
...