XPath variables

Note

This technique is recommended for advanced users only.

Depending on the size and nature of the XML documents evaluated using XMLProbe, performance may be enhanced by using XPath variables.

Performance degradation of (unoptimised) XPath processors often occurs where typically large nodesets are evaluated against one another, for example:

//foo[ . = //bar[@blort] ]

In this case, /descendant-or-self::node() (abbreviated to //) occurs both in the main part of the expression and in the predicate. XPath expressions of this sort can exhibit quadratic behaviour.

Variable usage

XPath variables may be included in the ruleset anywhere the SILCN grammar allows. Each variable must have a valid XPath name and an XPath expression, as follows:

<silcn:set-criterion>
<silcn:id>variable-test</silcn:id>
<silcn:expression>//foo[ . = $bar-blorts ]</silcn:expression>         
<probe:variable>
<probe:name>bar-blorts</probe:name>
<probe:eval>//bar[@blort]</probe:eval>
</probe:variable>
<probe:message>found a foo equal to a bar/@blort</probe:message>
</silcn:set-criterion>

XMLProbe evaluates all variables so declared and caches the results before evaluating the QA rules. Variables are global in scope, and may be referenced from within any rule in the ruleset. Note that declaring a variable with the same name twice is not an error, and that therefore the latest declaration holds.

Limitations

This technique is best used where large nodesets are reused in a ruleset. While it is tempting to include XPath variables wherever possible throughout a ruleset, a point may be reached where this kind of optimisation is no longer beneficial.