XQuery 4.0: An XML Query Language

Note:

The keyword map was required in earlier versions of the language; in XQuery 4.0 it becomes optional. There may be cases where using the keyword improves readability.

In order to allow the map keyword to be omitted, an incompatible change has been made to XQuery computed element and attribute constructors: if the name of the constructed element or attribute is a language keyword, it must now be written using the QNameLiteral syntax, for example element #div {}.

Although the grammar allows a MapConstructor to appear within an EnclosedExpr (that is, between curly brackets), this may be confusing to readers, and using the map keyword in such cases may improve clarity. The keyword map is used in the second example above to avoid any confusion between the braces required for the then part of the conditional expression, and the braces required for the inner map constructor.

If the EnclosedExpr appears in a context such as a StringTemplate, the two adjacent left opening braces must at least be separated by whitespace.

Note:

In some circumstances, it is necessary to include whitespace before or after the colon of a MapConstructorEntry to ensure that it is parsed as intended.

For instance, consider the expression {a:b}. Although it matches the EBNF for MapConstructor (with a matching MapKeyExpr and b matching MapValueExpr), the "longest possible match" rule requires that a:b be parsed as a QName, which results in a syntax error. Changing the expression to {a :b} or {a: b} will prevent this, resulting in the intended parse. For instance, consider the expression {a:b}. Although it matches the EBNF for MapConstructor, the “longest terminal” rule (see A.3 Lexical structure) requires that a:b be parsed as a QName, which is likely to result in an error indicating that the prefix a has not been declared. Changing the expression to {a :b} or {a: b} will prevent this, resulting in the intended parse. For instance, consider the expression {a:b}. Although it matches the EBNF for MapConstructor (with a matching MapKeyExpr and b matching MapValueExpr)MapConstructor, the "longest possible match" rule“longest terminal” rule (see A.3 Lexical structure) requires that a:b be parsed as a QName, which results inis likely to result in an error indicating that the prefix a syntax errorhas not been declared. Changing the expression to {a :b} or {a: b} will prevent this, resulting in the intended parse.

Similarly, consider these three expressions:

{a:b:c}
{a:*:c}
{*:b:c}

In each case, the expression matches the EBNF in two different ways, but the “longest possible match” rule forces the parse in which the MapKeyExpr is a:b, a:*, or *:b (respectively) and the MapValueExpr is c. To achieve the alternative parse (in which the MapKeyExpr is merely a or *), insert whitespace before and/or after the first colon. In each case, the expression matches the EBNF in two different ways, but the “longest possible match” rule forces the parse in which the first subexpression is a:b, a:*, or *:b (respectively) and the second subexpression is c. To achieve the alternative parse (in which the first expression is merely a or *), insert whitespace before and/or after the first colon. In each case, the expression matches the EBNF in two different ways, but the “longest possible match” rule forces the parse in which the MapKeyExprfirst subexpression is a:b, a:*, or *:b (respectively) and the MapValueExprsecond subexpression is c. To achieve the alternative parse (in which the MapKeyExprfirst expression is merely a or *), insert whitespace before and/or after the first colon.

See A.3 Lexical structure.

Note:

There are also several functions that can be used to construct maps with a variable number of entries:

• map:build takes any sequence as input, and for each item in the sequence, it computes a key and a value, by calling user-supplied functions.

• map:merge takes a sequence of maps (often but not necessarily single-entry map^DM) and merges them into a single map.

• map:of-pairs takes a sequence of key-value pair maps^FO and merges them into a single map.

Any of these functions can be used to build an index of employee elements using the value of the @id attribute as a key:

• map:build(//employee, fn { @id })

• map:merge(//employee ! { @id, . })

• map:of-pairs(//employee ! { 'key': @id, 'value': . })

All three functions also provide control over:

• The way in which duplicate keys are handled, and

• The ordering of entries in the resulting map.