What is a ‘Full’ D-TRO Record?¶

When a TRA submits a new D-TRO record care is required to ensure that the record contains all necessary information - this is the responsibility of the TRA. The D-TRO Service will undertake various forms of validation to ensure that requirements have been met and the D-TRO record can be accepted.

Note

The test of what constitutes a D-TRO record that contains all essential elements and therefore can be considered to be a ‘full’ record is subject to review and learning from prototyping. This section is therefore likely to change with new releases.

Validation Rules¶

Two primary forms of validation test are foreseen:

Schema validation - this is a set of technical tests to ensure that that the data and the structure of the submitted D-TRO record conforms to the requirements of the Data Model and schema. These tests will check that mandatory elements of the Data Model exist in the D-TRO record; that additional elements not part of the Data Model are not provided; that supplied data conforms to prescribed data types (e.g. that a attribute typed as a datetime in the Data Model is actually a valid datetime); that enum types are valid, etc.
Semantic validation - this is a further set of technical tests cannot be enforced by schema validation. Examples include, but are not limited to:
- The mandatory troName, traCreator and traAffected attributes of the source object contains not only an integer value, as required by schema validation, but the value given matches a value in the TRA code list and corresponds to the sender’s TRA code (e.g., ‘116’ for Bristol City Council).
- Where start and end datetimes are provided, that the start datetime occurs before the end datetime

A set of validation tests have been created, which are summarised in the tables below. A detailed document of the validation rules is available in the GitHub repository.

Appropriateness-related rules help keep the data within the D-TRO service as relevant as possible and does not contain biases, which make them unfit for use by the Software Providers.

Table 4 Appropriateness-related validation rules¶
Rule Type	Description
Nature of business rules	Some TRO data will apply to specific consumer types or across different consumers. Selection and use of the right set of data ensures that it is relevant for each user type and provided in the appropriate way.
Entity-status relationships	Provisions cannot be linked to TROs if the status of one is inappropriate.
Currency rules	Appropriate currencies and timing considerations are used.
Retention rules	Record is retained for X period after trigger Y, e.g. keep inactive TROs for a maximum of 3 years from time of becoming inactive.
Data consistency	TROs that are duplicated (for performance, redundancy, etc) should be consistent with the original values, and be subject to the same domain and data quality rules.

Completeness rules ensures that the Data Model provides comprehensive information for the digitalisation and analysis of TROs.

Table 5 Completeness validation rules¶
Rule Type	Description
Entity completeness	The full set of entities are present, i.e. all TRO records with provisions are present
Relationship completeness	Referential integrity is correct between TROs and provisions i.e. all relationships between entities can be resolved.
Attribute completeness	All required attributes for TRO entities are present i.e. all necessary columns are populated
Domain completeness	All required attributes contain an allowable value, and intentionally set nulls can be differentiated from absent values
Identity / uniqueness rules	Every TRO record must exist only once, be uniquely identifiable, relate to exactly one real-world entity with attributes not being overloaded – e.g. containing different regulation types in a single field
Entity-relationship constraints	The existence of one relationship mandates or prohibits the existence of another, e.g. an “Amend” or “Revoke” provision must be linked to an existing D-TRO record.
Attribute-relationship constraints	The allowable values of one or more values mandates or prohibits the value (or existence) of another, e.g. A vehicle dimension populated for a size-based restriction.
Event-relationship constraints	Links that must exist for an instance to occur, e.g. activation / inactivation of a TTRO must have an existing TRO present.
Optionality constraints	Attributes have defined list of options to populate with, e.g. the Speed Limit value.
Inheritance rules	Existence of all necessary fields from combination of super-type and sub-type. Correct application of implied rules through sub-typing, e.g. activation notices for TTROs.
Granularity rule	Historic data is kept for the same period at similar level of granularity.
Continuity rule	No gaps or overlaps in historic or time series data for D-TROs, e.g. contradictory time ranges for overlapping TROs.
Event dependencies	Relating separate events that are likely to be consistent in time, e.g. connection between consultation and the provision of an active TRO.

Accuracy-related rules ensure the degree of confidence that can be placed in the data from the D-TRO service. Data must be sufficiently accurate as standardised data to support the defined use cases and avoid material distortion in the central storage system.

Table 6 Accuracy-related validation rules¶
Rule Type	Description
Data accuracy	An attribute must be representative of its real-world state as per the TRO.
Valid value constraints	A list of values, a range of values, a constraint on values, a set of allowable characters as part of the D-TRO.
Format constraints	For dateTime, Values, Geographical Coordinates and other specific formats for fields.
Precision constraints	The values in the field must be the same precision as the attribute requires in response to D-TRO requirements, business rules and intended meaning, e.g. vehicle dimensions.
Definition constraints	The values match the intended meaning of the attribute, e.g. coordinate type reflects the value of coordinates entered.
Attribute constraints	One attribute can be derived from one, two, three or more others, e.g. parking duration restrictions.
Timestamp pattern rule	Ensuring dates and times are within correct ranges.
Reference rule	Ensure a reference system is implemented at each TRA level for tracking previous changes done to its D-TROs
Action rule	Each D-TRO must have one action at the source and provision level provided by the TRA that issues the D-TRO.