General comparisons are used for comparing atomic values or nodes that contain atomic values. Table 3-2 shows some examples of general comparisons. They use the operators = (equal to), != (not equal to), < (less than), <= (less than or equal to), > (greater than), and >= (greater than or equal to). Unlike in XSLT, you don't need to escape the < operator as <; in fact, it won't be recognized if you do.

If either operand is the empty sequence, the expression evaluates to false.

doc("catalog.xml")/catalog/product/@dept = 'ACC'

<myNewEl>{"a", "b", "c"}</myNewEl>

if (not($prod))
then (<empty/>)
else (<name>{data($prod/name)}</name>,
      <num>{data($prod/number)}</num>)

doc("catalog.xml")//product, doc("order.xml")//item

Value comparisons differ fundamentally from general comparisons in that they can only operate on single atomic values. They use the operators eq (equal to), ne (not equal to), lt (less than), le (less than or equal to), gt (greater than), and ge (greater than or equal to). Table 3-3 shows some examples.

Unlike general comparisons, if either operand is the empty sequence, the empty sequence is returned. In this respect, the empty sequence behaves like null in SQL.

Each operand of a value comparison must be either a single atomic value, a single node that contains a single atomic value, or the empty sequence. If either operand is a sequence of more than one item, a type error is raised. For example, the expression:

doc("catalog.xml")/catalog/product/@dept eq 'ACC'

raises an error, because the path expression on the left side of the operator returns more than one dept attribute. The difference between general and value comparisons is especially important in the predicates of path expressions.

When comparing typed values, value comparisons have similar restrictions to general comparisons. The two operands must have comparable types. For example, you cannot compare the string "4" with the integer 3. In this case, one value must be explicitly cast to the other's type, as in:

xs:integer("4") gt 3

However, value comparisons treat untyped data differently from general comparisons. Untyped values are always treated like strings by value comparisons. This means that if you have two untyped elements that contain numbers, they will be compared as strings unless you explicitly cast them to numbers. For example, the expression:

xs:integer($prodNum1) gt xs:integer($prodNum2)

explicitly casts the two variables to the type xs:integer.

You also must perform an explicit cast if you are comparing the value of an untyped element to a numeric literal. For example, the expression:

doc("catalog.xml")/catalog/product[1]/number gt 1

will raise a type error if the number element is untyped, because you are essentially comparing a string to a number. Because of these complexities, you may prefer to use general comparisons if you are using untyped data.

declare namespace functx = "http://www.functx.com";
declare function functx:between-inclusive
 ($value as xs:anyAtomicType, $minValue as xs:anyAtomicType,
  $maxValue as xs:anyAtomicType) as xs:boolean  {

   $value >= $minValue and $value <= $maxValue

 };

functx:between-inclusive ($prod/number, 1, 500)

Another type of comparison is the node comparison. To determine whether two operands are actually the same node, you can use the is operator. Each of the operands must be a single node, or the empty sequence. If one of the operands is the empty sequence, the result is the empty sequence.

The is operator compares the nodes based on their identity rather than by any value they may contain. To compare the contents and attributes of two nodes, you can use the deep-equal built-in function instead.

Table 3-4 shows some examples of node comparisons. They assume that the variables $n1 and $n2 are bound to two different nodes.

In the last example of the table, even though the second and third products have the same value for their dept attributes, they are two distinct attribute nodes.