Using Schematron - Rules
(Page 4 of 4 )
So far, the assertions we've made have all dealt with residents. In fact, the XPath expressions we've used for the assertion tests have operated in the context of resident elements. This is of course consistent with the way Schematron works; assertions are not just placed into a schema definition as-is. Assertions are grouped into rules. All of the assertions in a given rule share the same context. A rule context is a group of elements that the rule will act upon.
It is possible, then, to group all the assertions we've made under a single rule acting upon the resident elements of a document. Let's go ahead and wrap all of the assertions we've made into a single rule element. The context attribute of the rule element contains the context expression which, in this case, would simply be the resident element. The context expression is an XPath expression.
<rule context="resident">
<assert test="(age < 18 and eligible_to_vote = 'no') or age > 18">
If the resident's age is below 18, then the resident should not be able to vote.
</assert>
<assert test="(status = 'alien' and eligible_to_vote = 'no') or status = 'citizen'">
Aliens cannot vote.
</assert>
<assert test="age">
A resident has an age.
</assert>
<assert test="status">
A resident has a status.
</assert>
<assert test="eligible_to_vote">
A resident must have a voter eligibility value.
</assert>
</rule>
As you can see above, a rule by itself does not have to be complex. After all, it's just a group of assertions bundled together with the same context. Of course, the context expression could have been more complicated, but the basic principle is very simple.
A more complex feature of rules is the ability to "inherit" from another rule. It's possible in Schematron to create a special rule called an abstract rule that by itself has no context. Other rules can then extend the abstract rule and provide a specific context. Notice how abstract rules are similar to abstract classes in programming languages. By themselves, they don't do anything, but they pass their members down to child classes.
Abstract rules are used to save space by bundling common assertions together. For example, suppose that we created an element to represent a tourist, and that we put tourists along with residents in the same document. Both tourists and residents would share an age element. So, if we wanted to check for the presence of the element in both, we could create an abstract rule containing this assertion. The rule has to be given an identifier using the id attribute (so that we know what we're extending later), and we have to declare it abstract by using the abstract attribute. Let's go ahead and create this abstract rule:
<rule id="personRule" abstract="true">
<assert test="age">
A resident has an age.
</assert>
</rule>
In order to extend it in another rule, we'd simply introduce an extends element, whose rule attribute points to the abstract rule to be extended:
<rule context="resident">
<extends rule="personRule" />
...
</rule>
<rule context="tourist">
<extends rule="personRule" />
...
</rule>
Above, we declare two rules, one which applies to residents and one which applies to tourists. Both rules will contain the assertion in the abstract rule without having to define it over again.
Please check back next week for the second part of this series.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
