ASSETS VERSIONED IN GIT MANDATORY

Table of Contents

4.6.1. Introduction

In order to facilitate interoperability for the Evidence Exchange, a set of business rules is defined which must be applied in each transaction (Evidence Request, Evidence Reponse, Error Response).  The transactions are distinguished by different rule IDs:

• EDM-REQ: The rule ID references to the transaction "Evidence Request" (section 4.5.1).
• EDM-RESP: The rule ID references to the transaction "Evidence Response"   (section 4.5.2). 
• EDM-ERR: The rule ID references to the transaction "EDM Error Response" (4.5.3).

For each business rule, a corresponding schematron rule is defined that references the same rule ID. The business rules are sets of rules that guarantee the correct structure of the transactions and they clarify the content of instances by stating mandatory fields, fixed values (like code lists), the dependency between fields in the same object and dependency between different objects. The business rules are grouped into two main sections depending on their scope:

• Structure: Business rules that guarantee the correct structure of the message use the prefix "S" before the numer (e.g. S009):
  • Check information constraints related to the use of different components such as namespaces, root elements, slots, data types including "multidimensional" checks crossing the barrier between the different XSD schemes (XSD-Binding and XSD-Restriction).
• Content: Business rules that ensure the correct content format of information objects use the prefix "C" before the numer (e.g. C012):
  • Check cardinalities, identifiers, formats, fixed values, mandatory set of values on specific fields (code lists) and dependencies between fields;

Each business rule is associated with an error level (role) that expresses a validation result when an XML instance is proven against the rules through schematron validation:

• caution: A hint that an additional object is needed in some cases; It may not be wrong, but care is required.
• warning: Offering recommendations to improve the quality of the instance or regain full validity; Something wrong has happened, but it does not necessarily require action. 
• fatal: The rule point to a major issue of consistency or data correctness. Something so bad that processing or validation should or did stop. 

The rule type classifies the principle goal of a business rule. The rule ID is used to identify the rule and can be used as an error level next to the rule description. Rule descriptions containing "MUST" correspond to an error level that is flagged with role fatal, leading to a termination of the process while "SHOULD" rules correspond to an error level that is flagged with role warning. The process can continue in this case. "MAY" rules point to error level flagged with role caution and are indications that also do not lead to a process termination. The Element and Location points to the correct information object that is affected by the rule.