Databases Reference
In-Depth Information
Another approach is to use an XPath predicate within the rules context attribute to
narrow down the context to a specific card type. For example, we can specify a set of
assertions for credit cards of type
MasterCard
as follows:
<rulecontext="cmn:creditCard[cmn:cardType='MasterCard']">
<asserttest="string-length(cmn:cardNumber)='16'">
Mastercardcardnumbermustbe16digits.
</assert>
<asserttest="string-length(cmn:securityNo)='3'">
SecuritycodeforMastercardmustbe3digits.
</assert>
</rule>
Using this approach, we can specify a different rule for each card type, allowing us
to maintain assertions for each card type independently from one another as well as
simplifying the process of adding new card types.
Using XPath 2.0 functions
In the previous assertion, we are just testing that
cardNumber
is 16 characters in
length, but we are not checking that it's an actual integer. We are relying on schema
validation for this.
There is nothing wrong with this approach, but what if some cards allowed
alphanumeric numbers? In this scenario, we would need to declare
cardNumber
as a
string and then carry out specific validation in Schematron to check the format of the
element based on
cardType
.
For this, we can use the
matches
function to test whether the content of the element
conforms to a particular regular expression. However, this is an XPath 2.0 function,
so in order to use this within Schematron, we need to define its namespace. We do
this in exactly the same way as we would for any other namespace, that is:
<nsuri="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.
services.functions.Xpath20"prefix="
xp20
"/>
We can then create an assertion that matches the
cardNumber
, like this:
<asserttest="
xp20
:matches(cmn:cardNumber,'[0-9]{16}')">
Mastercardnumbermustbe16digits.
</assert>
