Other Aspects of XPath 1.0 | SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)

We've described location paths at length and now sprint through aspects of XPath 1.0 that are more like other languages. For additional details, refer to descriptions in your product documentation, which should include product-specific extensions, if any.

Expressions

XPath 1.0 expressions resolve to

Boolean values that are directly available by invoking the functions true() and false()
strings
numbers (double-precision, 64-bit floating point)
node sets

In relation to Booleans, strings, and numbers, the XPath 1.0 processor automatically converts from one type to another in accordance with the XPath functions string(), number(), and Boolean():

When a comparison of one operand to another is based on the equal sign or the not-equal sign (!=), data-type conversions occur as follows:
- A comparison that includes a Boolean is a Boolean comparison.
- A non-Boolean comparison that includes a number is a numeric comparison.
- A comparison that lacks Booleans and numbers is a string comparison.
When a comparison of one operand to another uses <=, <, >=, or >, the comparisons are numeric.
A zero is equivalent to a Boolean false, and any non-zero number is equivalent to a Boolean true.
A string with any value is equivalent to a Boolean true, and a string with no characters is equivalent to a Boolean false.
The characters NaN mean not a number and may appear in a situation where you've tried to convert a string such as Hello! to a number.

In relation to node sets, the following rules are in effect:

A comparison of two node sets evaluates to true if the string value of any node in the first node set is the same as a string value of any node in the second. The following example resolves to true because each of the two node sets includes a node whose string value is Sport:
```
 /descendant::CarPolicy[1]/Vehicle/@Category = /descendant::CarPolicy[2]/Vehicle/@Category 
```
One implication is that an equality comparison of one node to another is a comparison of string values and is never a comparison to determine whether the nodes are the same.
A comparison of a node set to a number evaluates to true if the string value of a node in the node set can be converted to that number, as in the next example.
```
 /Insured/@CustomerID = 5 
```
A comparison of a node set to a string evaluates to true if the string value of a node in that node set is equivalent to the string, as in the next example.
```
 /Insured/@CustomerID = '5' 
```
A node set evaluates to true in a Boolean comparison if the node set includes at least one node. The following evaluates to true because the XML source includes at least one Make element whose string value is Porsche and at least one Model element whose string value is Mustang.
```
 /descendant::Make[.='Porsche'] and /descendant::Model[.='Mustang'] 
```

As mentioned earlier, a predicate can accept any Boolean expression. The following expression returns any Vehicle node whose Make child has the string value Ford and whose Model child has the string value Mustang.

 /descendant::Vehicle[child::Make = 'Ford'][child::Model = 'Mustang']

That expression returns the second Vehicle node, as does the next expression, which is the same but omits references to the child axis specification.

 /descendant::Vehicle[Make = 'Ford'][Model = 'Mustang']

Last, we want to shed light on a confusing aspect of Boolean logic in XPath. Our focus is twofold: the effect of the not-equal operator when it is used to compare a node set and a string, and the effect of the not() function, which returns the opposite of the Boolean value that is passed to it.

We offer four examples:

The first expression evaluates to true if one or more Make nodes has the string value Buick.
```
 /descendant::Make = 'Buick' 
```
The second expression evaluates to true if no Make node has the string value Buick.
```
 not (/descendant::Make = 'Buick') 
```
That is, the example evaluates to false if any Make node has the string value Buick.
The third expression evaluates to true if one or more Make nodes has a string value that is not Buick:
```
 /descendant::Make != 'Buick' 
```
That is, the example evaluates to false only if every Make node has the string value Buick.
The fourth expression evaluates to true only if every Make node has the string value Buick.
```
 not(/descendant::Make != 'Buick') 
```

The subtle difference in meaning between the second and third expressions causes a big difference between the first and fourth.

Consider the first and third expressions again and ask yourself, "What do the following Boolean expressions have in common?"

 /descendant::Make[position() &lt; 3] =    /descendant::Make[position() &lt; 3] /descendant::Make[position() &lt; 3] !=    /descendant::Make[position() &lt; 3]

Both Boolean expressions evaluate to true. The first expression evaluates to true because at least one node in the first node set has the same string value as at least one node in the second node set. The second expression evaluates to true because at least one node in the first node set has a string value that is different from the string value of at least one node in the second node set.

Aren't you glad you asked?

Numeric and Boolean Operators

Table 6.1 lists the numeric and Boolean XPath operators in order of decreasing precedence. The operators in a given cell are processed in left-to-right order in a given expression.

Table 6.1: XPath numeric and Boolean operators
Open table as spreadsheet
Operator	Meaning
^* div mod	Multiply Divide Use modular arithmetic, where the output is negative only if the dividend is negative: 7 mod 3 yields 1 7 mod 3 yields 1 -7 mod -3 yields -1 -7 mod -3 yields -1
+ -	Plus Minus
<= << >= >>	Less than or equal to Less than Greater than or equal to Greater than
= !=	Equal Not equal
and	Boolean and
or	Boolean or

Functions

The next sections give a brief overview of most XPath 1.0 functions. For further details, see your product documentation.