Registers Specification (v2)

Evolve

  1. Backwards compatibility
  2. Forwards compatibility

Backwards compatibility

Backwards compatibility requires that once a data attribute is introduced its semantics don't change.

Forwards compatibility

Forwards compatibility requires that tools consuming a register MUST apply the “must-ignore” rule for unknown attributes and assume that a missing known attribute is a missing value.

A missing value for a known attribute MUST be treated as the canonical form for an empty value (i.e. empty string for cardinality 1 or empty set for cardinality n).

For example, given a schema such as:

Schema
  [ Attribute { id = "name", datatype = One String, ... }
  , Attribute { id = "start-date", datatype = One Datetime, ... }
  , Attribute { id = "end-date", datatype = One Datetime, ... }
  ]

When given a data blob such as:

Blob
  [ ("name", "Walnut")
  , ("group", "allergen:24")
  ]

The “must-ignore” rule applies by ignoring the unknown group datum:

Allergen
  { id = ID "32"
  , name = Just "Foo"
  , startDate = Nothing
  , endDate = Nothing
  }

When instead, the data blob is:

Blob
  [ ("name", "foo")
  , ("start-date", "2018-08-14")
  ]

The “missing-value” rule applies to end-date; a consumer must assume the value for end-date is unknown and as such the follwing data blob is isomorphic:

Blob
  [ ("name", "Foo")
  , ("start-date", "2018-08-14")
  , ("end-date", "")
  ]

And when applying the schema, it can be seen as:

Allergen
  { id = ID "32"
  , name = Just "Foo"
  , startDate = Just (Datetime 2018 8 14)
  , endDate = Nothing
  }

In other words, the Allergen type would be defined with all its attributes as optional:

type Allergen
  { id : ID
  , name : Maybe String
  , startDate : Maybe Datetime
  , endDate : Maybe Datetime
  }

© Crown copyright released under the Open Government Licence.