Data structures are described in the specification
A data record the domains pass to one another or keep in a store is described by a node of its own, a data record node: its name, what it is, each of its fields with its type in neutral terms, any bounds on the field's value included, whether the field is required and what it says, what happens to a field nobody declared, and, where another data record refers to it by an identifier, the field that identifies it. The rules that bind one field to another are rules linked to the data record.
The implementation's types and its checks of data at runtime are generated from the data record nodes and never written beside them; which mechanism performs the checks is described in the technical appendix.
Written beside the description, a type or a check is a second copy of the same structure and drifts from it; generated, the two cannot disagree. A structure is part of what the system is, so it belongs in the specification rather than in the code. The bounds a value may take are part of its type. An identifier of a data record has the type of the field that identifies it, so that field is named where the data record is described.
The links it makes
The links made to it
- cites ← The nodes are the specification
- refines ← A field is required only where its value is guaranteed
- refines ← A data record variant exists only for a value carrying fields of its own
- cites ← The test comes before the code
- implements ← What is checked, when, and what a failure costs
- cites ← The reviewer sees only the change and the nodes it names
- implements ← The commands
- implements ← Where the types and runtime checks generated from the data records are written
- implements ← What a data record node generates
- implements ← A data record its variants refine
- implements ← The type each neutral type of a field gives
The decisions taken on it
- Problem
A data record node could not say which values a number field may take, so the bounds of a setting were stated by no node while two components each checked them by hand.
- Ruling
The owner: the bounds go into the field's type, named as JSON Schema names them, and the check is generated from them, over writing them in the field's words or dropping them.
- Problem
The rule had every value choosing a form be a form, so a value carrying nothing got a form holding nothing, and it did not say when a field is required, so values that may not come were required; worded in one long rule, it was hard to read.
- Ruling
The owner: base data, set beforehand or made by the system, is required; additional data is required where its case guarantees it and optional otherwise; a form exists only where a value carries fields of its own. The rule is divided: this one keeps what a data record node holds and that types are generated from it, and three rules of their own say when a field is required, when a value has a form, and where each value choosing a form is declared.
- Problem
No node could hold a data record's structure, and a data record whose body differs with its kind had no way to be described at all.
- Ruling
The owner: a data record is described by a node of its own, with its fields; a data record whose fields depend on its kind holds the fields common to every kind and those its kind brings.
- Problem
Nothing said what type an identifier of a data record has, and nothing named the field that identifies a data record.
- Ruling
The owner: an identifier has the type of the field that identifies the data record it names, which that data record's node names.
- Problem
A data record node could not say that a field of type list of always holds at least one member, so the bound would have been stated only in words and its check written by hand beside the data record.
- Ruling
The owner: a field's type carries every bound on the field's value, a list's on how many members it holds among them, and this rule names no type, so that which type takes which bound is said where the types are listed.