XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (273 page)

The production rules in XPath implicitly define the precedence of the different operators. For example, the rule for
OrExpr
defines it as a sequence of
AndExpr
operands separated by
or
operators. This is a convenient way of defining that the
and
operator binds more tightly than
or
. The precedence order of all the operators is summarized in Appendix A.

One consequence of this style of definition is that the simplest
OrExpr
consists of a single
AndExpr
with no
or
operator present at all. This leads to all sorts of surprises. For example, because of the way the grammar is written,
3
is not just an
IntegerLiteral
, it is also a
FilterExpr
, a
RelativePathExpr
, a
MultiplicativeExpr
, a
TreatExpr
, and quite a few other things besides. This means that I can't use the term
OrExpr
when I want to refer specifically to an expression that uses an
or
operator. Instead, I'll refer to this as “an
or
expression.” This distinction works quite well in most cases, and if there's any risk of confusion, then I'll try to spell out exactly what construct I'm talking about.