B - Advanced 3 - Importance of context
Table of contents
- 1. Purpose
- 2. Description
- 3. Instructions
- 3.1.1. 1: Making structured mandatory
- 3.1.2. 2: Testing
- 3.1.3. 3: Making remittance mandatory
- 3.1.4. 4: Testing
- 4. Conclusion
- 5. Further reading
Purpose of this section is to introduce importance of context and the importance of the logic in which validation rules are ran. Also, as with any coding, we should take note that validatoin rule is only doing what it is told, which sometimes may be different what we ourselves might mean.
Following steps are done here:
Before proceeding, we should make sure our project compiles as it is right now. This means that the previous invalid rule we have made in section 2 should be fixed.
Before testing, as a reminder, if testing by using validation service outside of Studio, project has to be deployed in addition to compliation to make changes visible.
We can test this by using the test file used in basic section. We should cover the following cases:
- Remittance is not given
- Remittance is given, Structured is not given
- Remittance is given, Strucutred is given.
Below are relevant snippets of XML which can be used in the test file:
We can now see that the only error will be given in the case when Remittance is given but not for the case when Remittance itself is missing.
In the testing phase, we can use the same file as before as well. Here we should now see that error will also be given in the case when Remittance is missing.
In the step 1, we only told the validation rule to make Structured mandatory and nothing else. Parent of structured, Remittance, is optional. Therefore, it was valid that Structured itself is missing as there is no requirement for it to be there.
When making validation rules, we have to know the exact case on how the logic of the validation rule should work. Is a certain element always mandatory? Is a certain element mandatory only when its parent is given?
Automatically generated validation rules always make one element mandatory and they never assume anything else. For this reason, in certain cases it is required to create multiple validation rules to make a whole XML tree to be mandatory if that is the case which is required.
It is also worth nothing that we do not have to make elements mandatory with OCL rule if they are already been made mandatory by schema. Theoretically it is possible to make these rules, but they would never trigger in the validation phase as a schema error would be given instead.
More information about context can be found here: https://wiki.xmldation.com/User_guide_for_OCL_rules_in_XMLdation_environment/2._Concept_of_Context
In order to proceed in these tasks, it is helpful to read the content in the wiki page but not required.