Evolve
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.