C OMPARECENCIAS ANTE LAS C OMISIONES

In this section, we provide a concise definition, i.e., the BNF rules shown in Figure 3.5, for the core fragment of the XQuery language handled in this dissertation.

e ::= vj(v)?xp j flwr jre

flwr ::= for-let where-return

for-let ::= for[v℄in[e℄ j let[v℄:=[e℄ where-return ::= (where )? returne

re ::= fe

1 gf..gfe

k

g j <tag>e</tag>

Figure 3.5: BNF Rules for XQuery Fragment In this set of BNF rules, xp denotes a path expression, fe

i

3.2. AN XQUERY FRAGMENT BEYOND XPATH 63

denotes a sequence of enclosed expressions,vis a variable, and is a where condition. We use[v℄to represent a sequence of variables defined in the given for-clause, and[e℄to denote their corresponding bound expressions. The XQuery fragment defined above is similar to the minimal XQuery defined in [DTCO03]. It is very close to the XQuery core used in the XQuery formal semantics proposal [W3C03d], being slightly more tolerant in allow- ing multiple variables to be defined in a single for-clause. This fragment allows us to focus on the core features of XQuery such as the existential qualifier “some”, the conjunction connective “and”, and the conditions in- volving only semi-interval arithmetic comparisons (i.e., only =,  or ) with constants.

In addition, our XQuery fragment contains only the well-behaved XPath fragment (i.e., the core XPath in [GK02]) that has been identified to have de- sirable features such as PTIME containment complexity [G. 02b]. To avoid recursive computations, we allow only the XPath expressions specifying downwards navigations. This XPath fragment is denoted asXP

f==;=;;[℄g , which is free of disjunction, negation and recursion.

However, we ignore other features such as user-defined functions, ag- gregations, arithmetic, string, namespace and position related operations. We do not deal with type switch or casting or the if-else constructs.

3.2.1 The Formal Semantics of the XQuery Fragment

In [W3C03d], formal notations such as expressions, XML values and en- vironments are used to reflect the meaning of the XQuery language with mathematical rigor. In particular, the dynamic semantics relate XQuery

expressions to the XML values to which they evaluate. This provides a reference for XQuery implementations.

As a functional language, XQuery utilizes the important concept of dy- namic environment, denoted dynEnv, as a dictionary structure that maps variables to data bindings [W3C03d]. That is,dynEnv = M(VarR ef ) Value). The symbol)means a judgment and is read as ”yields”.VarR ef denotes a set of variable references andValue represents the sets of data bindings associated withVarR ef.

In an XQuery, each expressioneis evaluated in a specific context where the information available is the mappings indynEnvat that time. This is captured by the ruledynEnv`e)Value. The symbol`indicates that the right hand side evaluation of expressioneyieldingValueis performed in the dynamic environmentdynEnv.

For anyvoccurring ine, its evaluation is a “looking up” ofv’s bindings indynEnv, denoteddynEnv:varValue(v). Ifeis a for clause, its evaluation may result in a list of new mappings, which will be added intodynEnv to provide the context for evaluating the next expression in order. Along with the evaluation of a query, the mappings held indynEnv evolve. For example, new mappings are added intodynEnv when new variables in a nested block are evaluated to be associated with their corresponding data bindings. The mappingValueof av indynEnvcan be overwritten ifv is asserted with new conditions in a nested block which results in different bindings. When the query evaluation exits a nested query block, the map- pings established in this block are removed fromdynEnv. This explains whydynEnvis called “dynamic” and why variables have their life scopes.

3.2. AN XQUERY FRAGMENT BEYOND XPATH 65

The formal semantics of our XQuery fragment, a restricted subset of the full XQuery [W3C03c], corresponds to the formal semantics for some of the primary expressions (i.e., literals, variable references, parenthesized ex- pressions, and context item expressions, referred to in Sections 4.1.14.1.4 in [W3C03d]), path expressions (see Section 4.2 in [W3C03d]), sequence expressions (see Section 4.3 in [W3C03d]), partial comparison expressions (i.e., value comparisons and general comparisons, referred to in Sections 4.5.14.5.2 in [W3C03d]), “and” logical expressions (see Section 4.6 in [W3C03d]), direct element constructors (see Section 4.7.1 in [W3C03d]), partial FLWR expressions (i.e., for, let, return expressions referred to in Sections 4.8.24.8.4 in [W3C03d]), and quantitative qualifier expressions (see Section 4.11 in [W3C03d]).

In brief, the core part of the formal semantics of our XQuery fragment can be captured by the following rules extracted from [W3C03d]:

(1)dynEnv`VarR ef )dynEnv:varValue(VarR ef)=Value

(2)dynEnv`e)Value

(3)dynEnv`forVarR ef ine)dynEnv+M(VarR ef )Value)

(4)dynEnv`e1;e2)Value1;Value2

Rule (1) captures the semantics of “looking up” variable bindings in dynEnv, denoted by dynEnv.varValue(VarRef). That is, dynEnv maps a variable name (i.e.,VarR ef) onto the variable’s current value (i.e.,Value). Rule (2) captures the semantics of an XPath or a return expression. In Rule (3), dynEnv is updated by adding the mappings M(VarR ef ) Value) yielded from the for clause. Rule (4) indicates that each expression in the

sequence is evaluated consecutively and the resulting values are concate- nated into one sequence. We can see the evaluation of a query by applying these rules as an incrementaldynEnvbuilding process.

The XQuery fragment we focus on allows great flexibility in employing a variety of query constructs. For instance, XPath expressions help to select nodes from the source document, and nested FLWR expressions make it possible to specify variable bindings, impose conditions and construct the nested result structure. The features considered in this XQuery fragment all have some affordable computational complexities with respect to the containment problem.

The arbitrary nesting of FLWR expressions is more flexible than that of select-from-where clauses in SQL. For example, the inner SQL sub-queries produce the value domain that can serve as the condition constraints for the outer sub-query, while only the outermost select-clause in an SQL query can project attributes as output. In contrast, the construction of new ele- ments and the return of data bindings can occur at any nesting level of the FLWR expressions. Moreover, the nested SFW-clauses in an SQL query can be de-correlated to be represented as a regular join operation in a straight- forward way. It would be difficult to apply such a de-correlation approach directly to the nested FLWR expressions since this may distort the return semantics and cause an undesired unnesting of the variable bindings.