2. Concept of Context
Context is the main part in a business rule. Together with restriction and query they form a business rule. It could be described as an address or a starting point for the rule. It defines which part of the XML message is being checked by the restriction.
Context is always given as an element type as it is defined by a schema.
Below is a screenshot of a reference schema viewed in XSD editor (XMLspy):
Each box depicts an XML element, first row stating the name and second for stating the type. Type is not mandatory to be defined, and in the above schema "Message" element only has children and name.
It is crucial to note that a single 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 PartyIdentification.
Additionally, one type may be present multiple times in an XML file, even though it is defined only once in schema. Transaction, for example does not have maximum occurrences defined.
Behaviour of context in XMLdation service
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 make Nm mandatory for Cdtr and Dbtr when parent is given, we could write a rule using "PartyIdentification" as context. However, if we wanted to only make Dbtr/Nm mandatory, 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".