XML Static Analyzer User Manual

The solver allows automated verification of properties that are expressed as logical formulas over trees. A logical formula may for instance express structural constraints or navigation properties (like e.g. path existence and node selection) in finite trees.

A decision procedure for a logic traditionally defines a partition of the set of logical formulas: formulas which are satisfiable (there is a tree which satisfies the formula) and remaining formulas which are unsatisfiable (no tree satisfies the given formula). Alternatively (and equivalently), formulas can be divided into valid formulas (formulas which are satisfied by all trees) and invalid formulas (formulas that are not satisfied by at least one tree). The solver is a satisfiabilitytesting solver: it allows checking satisfiability (or unsatisfiability) of a given logical formula. Note that validity of a formula ϕ can be checked by testing ¬ϕ for unsatisfiability.

The solver can be used for reasoning over finite ordered trees whatever these trees do actually represent. In particular, the logic and the solver are specifically adapted for formulating and solving problems over XML tree structures [Bray et al., 2004]. The logic can express navigational properties like those expressed with the XPath standard language [Clark and DeRose, 1999] for navigating and selecting sets of nodes from XML trees. Additionally, the logic is expressive enough to encode any regular tree language property (it subsumes finite tree automata). It can encode constraints definable with common XML tree type definition languages (such as DTD [Bray et al., 2004], XML Schema [Fallside and Walmsley, 2004], and Relax NG [Clark and Murata, 2001]). The logic provides high-level constructs specifically designed for reasoning directly with such XML concepts: the user can directly write an expression using XPath notation in the logic, or even refer to an XML type in the logic. These characteristics make the system especially useful for solving problems like those encountered in the static analysis of XML code, static verification of XML access control policies, XML data security checking, XML query optimization, and the construction of static type-checkers, and optimizing compilers for a wide variety of tree-manipulating programs and XML processors.

Outline This user manual is organized as follows: Section 2 describes the basics for using the solver without requiring any logical knowledge; Section 3 gives some insights on the logic, especially on the simple yet general data tree model used by the logic (Section 3.1) and on the syntax of logical formulas (Section 3.2) including high-level constructs for embedding XPath expressions and XML tree types directly in the logic. Finally, Section 4 provides an overview of the background theory underlying the logic and its solver, with related references.

The logical solver is shipped as a compressed file which, once extracted, provides binaries along with all required libraries. The “solver.jar” executable file takes a filename as a parameter1 . The filename refers to a text file containing the logical formula to solve. For example, provided a recent2 Java runtime engine is installed, the following command line: java -jar solver.jar formula.txt runs the solver on the logical formula contained in “formula.txt”. The full syntax of logical formulas is given in Section 3.2. The following examples introduce the logical formulation of some simple yet fundamental XML problems, and how the solver output should be interpreted.

Example 1: emptiness test for an XPath expression. The most basic decision problem for a query language is the emptiness test of an expression: whether or not a query is self contradictory and always yields an empty result. This test is important for error-detection and optimization of host languages implementations, i.e. implementations that process languages in which XPath expressions are used. For instance, if one can decide at compile time that a query result is empty then subsequent bound computations can be ignored. For checking emptiness of the XPath expression a/b[following-sibling::c/parent::d], the contents of the “example1.txt” file simply consists of the following line: The input XPath expression is first parsed and compiled into the logic. The corresponding logical translation whose satisfiability is going to be tested is printed. The solver then computes the Fisher-Ladner closure and the Lean of the formula: the set of all basic subformulas that notably defines the search space that is going to be explored by the solver (see [Genevès et al., 2007] for details). The solver attempts to build a satisfying tree in a bottom-up way, in the manner of a fixpoint computation that iteratively updates a set of tree nodes. This computation is performed in at most 2 O

…(Full text truncated)…