eu.cdevreeze.xpathparser.ast

Additive expression. Addition/subtraction is left-associative.

And-expression. The "and" operator is associative, so the AST could have been left-associative or right-associative.

Arrow expression. The arrow operator is left-associative.

Axis step. For example: "child::book[@pageCount > 800]". The "[]" operator for adding predicates is left-associative.

Braced URI literal.

Comparison expression, where the optional comparison operator is a value comparison operator, general comparison operator or node comparison operator.

EQName, so either a URIQualifiedName or a QName.

Optional expression enclosed in braces.

Expression, which is a sequence of 1 or more ExprSingle objects, separated by commas. The "comma" operator is associative, so the AST could have been left-associative or right-associative.

Expression-single, that is, an expression without any top-level commas. Most XPath expressions are expression-singles.

Intersect or except expression, optionally using the "intersect" or "except" operator. These operators are left-associative.

Any leaf element in the AST of an XPath expression.

Multiplicative expression. The corresponding multiplication/division operators are left-associative.

NCName, that is, a non-colon name.

Names, as per the XML specification. See for example https://www.w3.org/TR/REC-xml/#NT-Name.

Only characters in the Unicode BMP (max. \uFFFF) are considered. So the range from #x10000 to #xEFFFF is not recognized as valid name characters in this implementation.

The functions of this class must be fast, because they are typically called very many times during parsing of XPath expressions.

Classes like NCName lean on this object. An NCName is an XML name without colon.

Or-expression. The "or" operator is associative, so the AST could have been left-associative or right-associative.

Path expression, so a relative path expression possibly preceded by "/" or "//" (or the expression "/" itself). Path expressions are used to locate nodes within trees.

Postfix expression, which is a primary expression succeeded by 0 or more predicates, arguments lists and/or lookups. Note that lookup (the "?" operator) is left-associative.

Primary expression, which are the basic primitives of the language. Examples are literals, variable references, function calls etc. Note that primary expressions can be rather simple but they do not have to be simple. For example, function calls can have arguments that are themselves quite complex expressions.

Range expression, where the optional range uses keyword "to" as operator.

Relative path expression, consisting of a number of step expressions separated by step operators ("/" and "//"). These step operators are left-associative.

Simple map expression, using the optional map operator ("!"). This operator is left-associative.

Single step in an absolute or relative path expression. Note that step expressions are either postfix expressions or axis steps.

String concatenation expression, where the optional string concatenation uses the "||" operator. String concatenation is left-associative.

Unary expression. The corresponding unary operators are right-associative.

Union expression, where the optional union uses operator "union" or "|". The union operator is associative, so the AST could have been left-associative or right-associative.

Binding of a variable name to an expression.

XPathElem that can introduce one or more variable bindings.

XPath 3.1 AST. The root of the type hierarchy is XPathElem. It offers the ElemApi query API.

The requirements on this AST are as follows:

• It must represent the syntax tree of a successfully parsed XPath expression

• It is not annotated with more semantic information, like type information that is not included in the XPath expression

• It does not know anything about the context in which it runs, like bound namespaces etc.

• It is rich enough to be able to serialize the AST back to XPath, knowing exactly where to place parentheses, braces, etc.

• It should help evaluation, so it should model operator associativity and precedence correctly, where feasible

• It must be readable in that object composition trees are not unnecessarily deep and therefore hard to comprehend

• Serialization of the AST to XPath may lead to differences in whitespace (and operator aliases), but other than that the result must be the same

• The AST class hierarchy does not have to use the exact same names as the XPath grammar

• Instances of the AST classes are easy to create in an ad-hoc manner, so they contain no parsing state

• The AST classes are case classes, with value equality and good support for pattern matching

It would be natural for the AST types to have IS-A relationships modeled as type inheritance, and HAS-A relationships modeled as composition. Where feasible, this approach has been followed. Consequently, sealed trait inheritance has been used a lot (IS-A instead of HAS-A), and unnecessarily deep object trees are prevented in this way.

Having such an AST of a successfully parsed XPath expression, it must be easy to reliably find used namespace prefixes, for example.

The AST, as well as the parser, were developed using the XPath 3.1 specification as input. In particular, see https://www.w3.org/TR/xpath-31/#id-grammar and https://www.w3.org/TR/xpath-31/#id-precedence-order. Note that the grammar in isolation does not clearly convey left or right associativity of operators, so the extra information about operator precedence and associativity is essential for understanding the "structure" of compound expressions.

TODO Improve several class names.

XPath expression.