Introduction.
The eXtensible Markup Language (XML) is widely used in many areas of computer software to represent machine readable data. XML provides a very simple language to represent the structure of data, using tags to label pieces of textual content, and a tree structure to describe the hierarchical content. XML emerged as a solution to data exchange between applications where tags permit to locate the content. XML documents are mainly used in databases. The XPath language [[BBC+07]] was designed as query language for XML in which the path of the tree is used to describe the query. XPath expressions can be adorned with boolean conditions on nodes and leaves to restrict the number of answers of the query. XPath is the basis of a more powerful query language (called XQuery) designed to join multiple XML documents and to give format to the answer.
In spite of the simplicity of the language XPath, the programmer makes usually mistakes when (s)he describes the path in which the data are allocated. Tipically, (s)he can omit some of the tags of the path, s(he) can add more than necessary, and (s)he can also use similar and wrong tag names. When the query does not match the tree structure of the XML tree the answer is empty. However, we can also find the case in which the query matches the XML tree but the answer does not satisfy the programmer. Due to the inherent flexibility of XML documents, the same tag can occur at different positions, and the programmer that makes a mistake can find answers that do not correspond to her(is) expectations. In other words, (s)he finds a correct path, but a wrong answer. We can also consider the case in which a boolean condition is wrong, expressing a wrong range, and several conditions that do not hold at the same time. When the programmer does not find the answer (s)he is looking for, there is a mechanism that (s)he can try to debug the query. In XML there exists an operator, denoted by `//', that permits to look for the tag from that position. However, it is useless when the tag is present in several positions, since in spite of the programmer finds answers, (s)he does not know whether they are closed to h(er) expectations.
XPath debugging has to take into account the previous considerations. Particularly, there is a underlying notion of chance degree. When the programmer makes mistakes, the number of bugs can be higher or lower, and the change degree is proportional to them, but there are several ways in which each bug can be solved, and therefore the change degree is also dependent from the number of solutions for each bug, and the quality of each solution. The quality of a solution describes the number of changes to be made. Finally, there is a case in which we have also focused our work. The case in which the mistake comes from a similar but wrong tag used. Here, the chance degree comes from the semantic closeness of the tag used.
We present a method for XPath debugging. We will describe how XPath expression can be manipulated in order to obtain a set of alternative XPath expressions that match against a given XML document. For each alternative XPath expression we will give a change degree that represents the degree in which the expression deviates from the initial expression. Thus, our work is focused on providing to the programmer a repertoire of paths that (s)he can use to retrieve answers.
The debugging process takes as input a XPath expression and an input XML document. Depending on the structure of the XML document the debugging process reports a set of alternative paths that match the document. The debugging is guided by the programmer that initially establishes a value (a real value between 0 and 1), that the debugger uses to penalize each bug. Each bug is found is penalized with such a value, and the change degree is thus proportional to such value. Additionally, we assume that the debugger is equipped with a table of similarities, that is, a table in which pairs of similar words are assigned to a value also between 0 and 1. It makes that change degree is also computed from similarity degrees.
The debugger reports a set of annotated paths in a XPath extended syntax in which we have incorporated three annotations: JUMP, SWAP and DELETE. JUMP is used to represent that the path expression has added some tag, SWAP is used to represent that the tag has been changed by another, and DELETE to represent that the tag has been deleted. The reported XPath expression has also updated the initial XPath expression, that is, JUMP includes '//' at the position in which the bug is found, SWAP includes the new tag, and DELETE erases the wrong tag.
The reported XPath expressions give information to the programmer about the changes to be made in the initial XPath expression to success about the input document. Additionally, our proposal permits that the programmer test the XPath expressions by calling annotated XPath expressions, obtaining a ranked set of answers depending on the change degree. It also facilitates the process of debugging since the programmer can visualize the answers to each query.
The implementation has been developed on top of the recently proposed fuzzy XPath extension [ALM11,ALM12], which uses fuzzy logic programming to provide a fuzzy taste to XPath expressions.
In spite of our approach can be applied to standard (crisp) XPath expressions, however, change degrees in XPath debugging fits well with our proposed framework. Particularly, XPath debugging annotations can be seen as annotations of XPath expressions similar to the proposed DEEP and DOWN of [ALM11,ALM12]. There DEEP and DOWN serve to annotate XPath expressions and to obtain a ranked set of answers depending on they occur, more deeply and from top to down. Each answer is annotated with a RSV (Retrieval Status Value) which describes the degree of satisfaction of the answer. Here JUMP, SWAP and DELETE work as annotations and penalize answers of debugged XPath expressions. Running debugged XPath expressions we obtain a ranked set of answers depending here on the change degree of the programmer. DEEP and JUMP have, in fact, the same behavior, JUMP proportionally penalizes answers as deep as they occur. In order to cover with SWAP with have incorporated to our framework similarity degrees.
Our approach provides a suitable framework for XPath debugging where the search of alternative paths to a given initial XPath expression can be easily implemented in a logic programming based approach.