When EIDR records are matched, created or modified, the data is validated in two ways:
- The data must first conform to the EIDR schema.
- The EIDR Registry then performs a number of additional validation tests that cannot be expressed in an XML schema.
This section summarizes the content validation tests. The rules are specified here from the perspective of each of the API functions (and not how the metadata record is eventually serialized or disseminated from the Registry). Note that the Match API skips those rules marked with an asterisk (*) below. Validation rules are included in the field descriptions in Sections 2 and 0, above.
Terminology (as used in tables below for each type of API method or operation: create, modify, etc.):
- Fixed: Implies the value set for the field is a controlled vocabulary.
- Fixed and conditional: Implies the value set for the field is a controlled vocabulary, but the actual values from the set depend on some other condition.
- Conditional: The actual values from the set depend on some other condition.
- Must be specified: Implies the value for the field must exist. The schema will enforce the format of the value.
- Must be absent: Implies the field must not exist.
- Enforced by schema: Implies no additional rule exists for the field besides what the schema already enforces. For certain field-type combinations, additional rules besides what the schema enforces are required. For those cases where additional rules are not required, this phrase would be used (in order to be thorough).
- Inherited from nearest ancestor if not specified: Implies the value for the field is inherited from its parent record if not Self-Defined in the current record.
- Not Applicable or blank rule: Implies no rule exists for the field regardless of whether the schema enforces or not.