Page Comparison

...

Recently, there has been increasing interest in representing the latter as reference records as well. This document is intended to outline the considerations for such an approach.

...

Design

...

Enumerations

Enumerations are defined directly with the property that they constrain, for example, this is the definition for the possible item status names:

{
  "name":{
    "description":"Name of the status e.g. Available, Checked out, In transit",
    "type":"string",
    "enum":[
      "Available",
      "Awaiting pickup",
      "Awaiting delivery",
      "Checked out",
      "In process",
      "In transit",
      "Missing",
      "On order",
      "Paged",
      "Declared lost",
      "Order closed",
      "Claimed returned",
      "Withdrawn",
      "Lost and paid",
      "Aged to lost"
    ]
  }
}

Reference Records

Characteristics

The two approaches have very different characteristics, particular in where they are defined, how they are referred to and how they can change.

Enumerations

• Are referred to by name
• Are defined by an interface
• Set is Members are fixed for any given module version
• Clients cannot dynamically get the members of set
• Are only a name, cannot have additional other descriptive properties associated with them
• Can only be referenced by a single property

Reference Records

• Are referred to by name
• Are defined by the implementation
• Set Members may change independently of module version
• Clients can dynamically get the members of the set
• Can have additional descriptive properties (beyond the name) associated with them
• Can be referenced by multiple properties

Comparison

Worked Example - Holdings Source

This feature is being worked on at present by the Core Functional team in preparation for the FoliJet team to disallow editing of holdings that are based upon imported MARC files.

Behaviour

• Assigned The source is assigned by different processes
  • If For holdings created during data import, the source should be MARC
  • If For holdings created any other way, the source should be FOLIO
• Can filter instances by whether there it has holdings with that source
• Dictates The source dictates whether instances holdings can be edited
  • Holdings with a MARC source cannot be edited directly
  • Otherwise holdings can be edited directly directly

Comparison

Table describing Below is a comparison of how the behaviour is achieved, and questions / impacts of that

Worked Example - Item Status

There is an upcoming feature for the ability for item statuses to be configurable by tenant. This example won't delve much into the details beyond trying to 

Impact of the characteristics

...

characteristics affect this (and related behaviour) behaviour.

Impact of the characteristics

When using reference records, the need to identify a specific member of the set (e.g. the checked out status) presents the significant possibility of implementation coupling between modules. This could undermine the notion that an interface implementation is replaceable.

If the set of reference records can be changed for a tenant (one of the powerful characteristics) then there needs to be an understand of how that effects other records or systems that refer to members of the set e.g. what happens if a status or type no longer exists?

Open Questions

• How do client modules identify a specific member of the set in order to attach meaning or semantics to it?

Summary

Related work

The Technical Council and Sys Ops SIG have been discussing how reference records should work, e.g. should users be able to change them? and how upgrades should affect them e.g. should a change to the modules default definition of reference records overwrite changes made by a user?

...