MALP and the XPath Debugger

The core of our debugger is coded with MALP rules by reusing most modules of our fuzzy-XPath interpreter [ALM11,ALM12]. And, of course, the parser of our debugger has been extended to recognize the new keywords DEBUG, SWAP, DELETE and JUMP, with their proper arguments.

Now, we would like to show how the new "XPath debugging" predicate admits an elegant definition by means of fuzzy MALP rules. Each rule defining predicate:

debugQuery(ListXPath,Tree,Penalty)

receives three arguments: (1) ListXPath is the Prolog representation of an XPath expression, (2) Tree is the term representing an input XML document and (3) Penalty represents the chance degree. A call to this predicate returns a truth-value (i.e., a tv tree) like the following one:

Basically, the debugQuery predicate traverses the XML document, checking the validity of the original query tag-by-tag, and trying to match each tag with the ones occurring in the XML document and thus producing effects of DELETE, JUMP and SWAP.

The definition of such predicate includes several rules for distinguishing the three debugging cases. As an example the case of swapping is defined as follows:

which becomes into the following Prolog clause after compilation into FLOPER:

Basically, similarity is checked with the atom similarity(Label, Label2), and two recursive calls are achieved for debugging both children (debugQuery(LabelRest, Children, Penalty)) and siblings (debugQuery([Label|LabelRest], Siblings, Penalty, 1)), whose tv trees are finally combined (fused) with the node content.

Finally, for showing the result in a pretty way, and transforming a tv tree into an XML file, a predicate tv_to_element has been implemented.

izmir escort- cratosslot baymavi vdcasino asyabahis tipobet