2. Concept of Context
Purpose and definition
Context defines the scope of the OCL-statement and thus is a main part of the rule as a whole. It defines which part of the XML message is being checked by the restriction defined in OCL-statement.
Context is always given as an element type as it is defined by a schema.
Below is a visual description of the reference schema.
Each row depicts an XML element, first column stating the name and second stating the type.
One type may be used in multiple places within the schema. Id, for example, is present under Header and Transaction and both of their types is Max35Text. Debtor and Creditor also share the type of PartyIdentification.
Additionally, even when type exists only once in schema, said type may be present multiple times in an XML file. Transaction, for example does not have maximum occurrences defined and it is possible for one XML-file to contain multiple Transaction elements (therefore multiple complexTypes TransactionType1).
Impact of element types in an XML file
The restriction defined in an OCL rule is always executed when its type is found in an XML file in the validation process.
This means that a rule with simpleType Max35Text as context will be executed every time a Max35Text element is found in the XML file. Similarly, context TransactionType1 is executed every time a Transaction is present in the file.
Consequences of this is that it can be used as a quick way to limit values for certain types when it is known that an exact business rule applies in many places. For example, if we wanted to limit Nm for Cdtr and Dbtr, we could write a rule using PartyIdentification as context. However, if we wanted to only limit Dbtr/Nm length and keep Cdtr/Nm length as it is, using PartyIdentification as context would lead to invalid consequences, as it would apply for Cdtr as well. In this case, context would have to be TransactionType1 and/or HeaderType1.
Please note that In order to make the examples in this section realistic, OCL-statements are included as well. OCL-statements are defined in the next wiki section, understanding them completely in this page is not required.
Debtor mandatory in header
The screenshot from myXML in the bottom left corner of this slide shows structure of one XML message. If we would like to create a rule which makes the debtor mandatory in the header we should set the context to be the Header.
- The OCL rule then ”sees” the part which is highlighted in the picture in the bottom right corner
- If context would be set to be the Debtor itself then the rule would not be run at all if debtor is missing.
Context: HeaderType1 OCL: self.Debtor->size() = 1
Limiting values in Max140Text
Max140Text type can be seen in three different places in the schema. Amount of Max140Text instances in a XML file conforming to this schema can however be more or less. In the below XML example four instances are found.
Rule having Max140Text as a context is executed against each instance found from the file
Below rule states that Max140Text element has to be shorter than or equal of 70 characters.
Context: Max140Text OCL: self.size() <= 70
Creditor name mandatory
Simple example of making a rule which sets one element to be mandatory requires some thought and planning beforehand to know what context to use.
For example, if we wanted to make a rule which sets Creditor / Name to be mandatory, setting context to be Max140Text would make the rule to be executed against all instances of Max140Text elements. Also if element of that type is missing, the rule would not be run. Setting context to be PartyIdentification, the rule would be run against all instances of that element, so also Debtors – and we only wanted to make Creditor name mandatory.
Correct context for making Creditor name mandatory would be to use TransactionType1 as context
Context: TransactionType1 OCL: self.Creditor->size() = 1 implies self.Creditor.Name->size() = 1