A literal is just a value that is of an atomic type. As we saw in Chapter 7, “What's New in XPath 2.0,” this means a value of a primitive simple type defined by the XML Schema specification, or a value of a type derived from them by restriction in a schema.

XPath 2.0 has built-in support for two types of literals—numeric literals and string literals. You can create a string literal simply by enclosing a string of characters in quotes, and numeric literals simply by writing the numeric value. You can see a simple example in ch08_01.xsl (Listing 8.1), which uses a string literal as an XPath expression.

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xsl:template match="/">
        <xsl:value-of select="'No worries!'"/>
    </xsl:template>

</xsl:stylesheet>

A string literal's value is an xs:string atomic type. You can simply enclose a string of characters in quotes, but be careful about nested quotes. For example, this literal is okay: “This is fine.” You can also use single quotes like this: 'This is also fine.' But what if you want to use quotation marks inside a string literal? In that case, you can nest single and double quotes, like this:

"I said, 'This literal is OK.'"

You can also use double quotation marks to indicate quoted text. For example, this string literal works just as the previous one did, except that the internal quoted text is delimited by two double quotes:

"I said, ""This literal is OK."""

Doubling single quotation marks works the same way:

'I said, ''This literal is OK.'''

By default, numeric literals that don't contain a “.” and contain no “e” or “E” (used to specify exponents), are of type xs:integer. For example, here are some integer numeric literals:

345
1
-9999

On the other hand, if your numeric value includes a “.”, but no “e” or “E”, XPath 2.0 assumes the literal is of the xs:decimal data type. Here are a few examples:

3.14159
-1.000
2.7128

If you include an “e” or an “E” character, XPath 2.0 assumes your numeric literal is an xs:double type. Here are a few examples:

3.14159E10
55.00e45
1.9e-5

Besides string and numeric literals, you can also use Boolean values, representing them with the built-in functions true() and false().

You can also create literals of any of the XML schema types using their constructors. We saw an example of how that works in Chapter 7, where we created an xs:date literal:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">

    <xsl:template match="/">
        <xsl:value-of select="xs:date('2004-09-02')"/>
    </xsl:template>

</xsl:stylesheet>

Here are a few other examples of creating literals based on XML schema types using the appropriate constructors:

xs:integer(45)
xs:decimal(3.14159)
xs:string("No worries!")

Variables are also expressions in XPath 2.0—the value of the expression is the value stored in the variable. In XPath 2.0, variables are valid XML names (that is, an XML QName), preceded by a $.

There are two sources of variables in XPath 2.0—the host language (such as XSLT), and those variables that you can define in XPath itself. For example, we've seen in Chapter 7 that you can create variables in XSLT using the <xsl:variable> element, and use them in XPath 2.0 like this:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:variable name="rightNow" select="current-dateTime()" />

    <xsl:template match="/">
        The date and time is:
        <xsl:value-of select="$rightNow"/>
    </xsl:template>

</xsl:stylesheet>

You can also use support for variables in XPath 2.0, as in these for and some expressions:

for $variable in /planets/planet return $variable/mass
some $variable in /planets/planet[1]/name satisfies $variable = "Mars"

When you're using multiple operators, such as multiple arithmetic operators, there can be some confusion about which operator is applied first. For example, what does 1 + 2 * 3 equal—3 * 3 or 1 + 6? It turns out that the multiplication operator is evaluated first, so 1 + 2 * 3 = 1 + 6 = 7.

On the other hand, if you wanted to add the 1 and 2 before multiplying the result by 3, you could use parentheses to indicate the order of execution you want:

(1 + 2) * 3

In XPath 2.0, parenthesized expressions like these are valid. (And don't forget that you can use an empty set of parentheses—()—to represent an empty sequence.)

Function calls are also considered expressions in XPath 2.0, and their value is simply the value returned by the function. For example, we took a look at the XPath 2.0 built-in max function in Chapter 7:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:template match="planets">
        <HTML>
            <HEAD>
                <TITLE>
                    The Largest Planetary Radius
                </TITLE>
            </HEAD>

            <BODY>
                <H1>
                    The Largest Planetary Radius
                </H1>
                <BR/>
                The largest planetary radius is
                <xsl:value-of select="max(//planet/radius)"/>
                miles.
            </BODY>

        </HTML>
    </xsl:template>

</xsl:stylesheet>

Here, the value of the function call is the sequence it returns.

Note that you can pass not only atomic values to functions, but also sequences. For example, this function call passes the values 4, 5, and 6 to a function:

function(4, 5, 6)

But this example passes a sequence consisting of 4 and 5, and then a value of 6:

function((4, 5), 6)

The context item expression is simply a dot, “.”, and as in XPath 1.0, it stands for the current context item. This can be a context node (the node from which evaluation of an expression starts), as in the path expression //planet[count(./name) > 1].

In XPath 2.0, context items can also be atomic values, as in this expression: (1 to 100)[. mod 10 eq 0], which returns the sequence (10, 20, 30, 40, 50, 60, 70, 80, 90, 100).

Each XPath 2.0 path expression must specify an axis (or use the default child axis), as in this location path: /library/book/title[2]/text. The XPath 2.0 axes are the same as the XPath 1.0 axes.

Note in particular that the namespace axis is now deprecated in XPath 2.0. That means that it's in a kind of limbo, preparatory to being phased out. Whether or not the software package you're using supports the namespace axis is now up to the package itself—it no longer has to.

When you use an axis in a location step, you're telling XPath 2.0 where to look and identifying a set of nodes. As in XPath 1.0, a node test tells XPath 2.0 which of the nodes in that set you're interested in.

There are two ways of creating node tests in XPath 2.0. You can use node names as node tests, along with a wildcard character, *, as in XPath 1.0. Or you can use “kind” tests like comment(), text(), and so on, as also in XPath 1.0. Here's an overview of the kinds of node tests you can use in XPath 2.0—note that element(), attribute(), and document-node() are new in XPath 2.0:

In XPath 2.0, you can pass parameters to the kind node tests element() and attribute(). Here are some examples (for more on type annotations, see the discussion on them in Chapter 7):

As in XPath 1.0, the next part of a location step, which follows the node text, is the predicate. A location step doesn't need a predicate, but using predicates, you can filter the nodes you want to locate even more.

Predicates are where you use the many XPath 2.0 functions when you want to use them in path expressions. This works as it does in XPath 1.0; for example, in the location step child::planet[position() = 2], the predicate is position() = 2. This means that the value the built-in XPath function position() returns must indicate that this is the second <planet> child in order for the location step to match. As in XPath 1.0, this location step can also be abbreviated as planet[2].

The rules for abbreviated syntax in XPath 2.0 are the same as in XPath 1.0 (technically speaking, . is not actually an abbreviation—it's the context node item, as discussed earlier.):

As you know from XPath 1.0, you can also abbreviate position expressions like [position() = 6] as [6]. That's all there is to abbreviated syntax. The next type of XPath 2.0 expression we'll take a look at is sequence expressions.

Here are a few examples; this sequence expression creates a sequence of six integers:

(9, 10, 11, 12, 13, 14)

In this case, we're creating a new sequence from the sequences 1, (2, 3), ()—that is, an empty sequence—and (4, 5, 6):

(1, (2, 3), (), 4, 5, 6))

This expression gives you the following sequence:

1, 2, 3, 4, 5, 6

Here's how you could create a sequence made up of all the <name> children of the context node, followed by all the <mass> children:

(name, mass)

You can also use variables or other expressions when creating sequences, like this:

($temperature, 3 * 6)

If $temperature holds 68, this example gives you this sequence:

(68, 18)

You can also use the range operator, as mentioned in Chapter 7, to create a sequence of integers. Here's an example:

(1 to 5)

This sequence expression creates the following sequence:

(1, 2, 3, 4, 5)

You can also use the range operator inside a sequence expression, like this:

(1, 2 to 5)

Here's the result:

1, 2, 3, 4, 5

What if you were to make the start and end of the range the same value by mistake? For example, how is XPath 2.0 supposed to handle this?:

9999 to 9999

In this case, the result is a singleton sequence with just one item, 9999.

XPath 2.0 also gives you a set of operators to work with sequences, as we saw in the overview in Chapter 7. We'll take a look at these operators—union, intersect, and except—which create sequence expressions, next.

a, b, union c, d, e

a, b, c, d, e

a, b, c union c, d, e

a, b, c, d, e

a, b, c intersect b, c, d

b, c

d, e, f intersect b, c, d

d

a, b intersect c, d

a, b, c except c

a, b

a, b, c, d except c, d, e

a, b

a, b, c except d, e, f

a, b, c

a, b, c except a, b, c, d, e

You use the value comparison operators when you're working with atomic values. Here they are:

These operators give you a result of true or false. Here's an example—say that $temperature holds the value 68; in that case, this expression would evaluate to true:

$temperature lt 72

This comparison is true only if $planet has a single <name> child element and its value is “Venus”:

$planet/name eq "Venus"

You can use general comparisons on sequences (including singleton sequences). Here are the general comparisons:

You use these operators on sequences. (What actually happens is that a value comparison operator, eq, ne, lt, le, gt, or ge—depending on which corresponding general comparison operator was used—is used to compare individual items in the sequence.) The software evaluating a general comparison usually will return a value of true as soon as it finds an item in the first operand and an item in the second operand for which the value comparison is true.

Here's an example pointing out how these operators deal with sequences, not just individual values. In this case, we're comparing two sequences, (1, 2) and (2, 3) with the general equality operator:

(1, 2) = (2, 3)

In this case, the result is true because the value 2 appears in both sequences.

Here, however, the result is false, because there is no value in the first sequence that is equal to a value in the second:

(1, 2) = (3, 4)

As with value comparisons, this comparison is true only if $planet has a single <name> child element and its value is “Venus”:

$planet/name = "Venus"

You can use node comparison expressions to compare nodes using the is operator.

A comparison expression with the is operator is true if the two operands are nodes that are identical; otherwise it is false.

For example, this comparison is true only if the left and right sides each evaluate to exactly the same single node:

//planet[name="Venus"] is //planet[days=116.75]

You use order comparison expressions to compare the order of nodes; both operands here must be either a single node or an empty sequence (if either operand is an empty sequence, the result of the comparison is an empty sequence). Here are the order comparison operators:

Using the << operator returns true if the first operand node is earlier than the second operand node in document order; otherwise it returns false. Using the >> operator returns true if the first operand node is later than the second operand node in document order; otherwise it returns false.

Here's an example:

//planet[name="Venus"] << //planet[days=116.75]

This example returns true if the node matched by //planet[name="Venus"] comes earlier in document order than the node matched by //planet[days=116.75].

Here's how you use the some quantified expression:

some in-claus(es) statisfies test-expression

A quantified expression like this starts with the some keyword, followed by one or more in-clauses, followed by the keyword satisfies, followed by a test-expression. What this expression does is to let you test if at least one item in the in-clause(s) satisfies the test expression.

Let's take a look at a few examples to make this clear. This expression is true if at least one of the <planet> elements in the document has a <name> child element:

some $planet in //planet satisfies $planet/name

Here's an example that tests if at least one <planet> element has a language attribute:

some $planet in //planet satisfies $planet/@language

In this way, you can use quantified expressions to test for the existence of items like elements and attributes.

You can also test logical conditions, as here, where we're making sure that at least one planet has a mass greater than 1.5:

some $planet in //planet satisfies ($planet/mass > 1.5)

Here's another example:

some $planet in //planet satisfies ($planet/name = "Mars")

You can also use multiple in-clauses in a some expression. Here's an example, where we're testing the product of numbers:

some $operand1 in (4, 5, 6), $operand2 in (7, 8, 9)
     satisfies $operand1 * $operand2 = 40

In this case, all possible combinations of the items in the in-clauses are tested—nine combinations in all. That is, 4 * 7 is tested, then 4 * 8, 4 * 9, then 5 * 7, 5 * 8, and so on.

Here's how you use the every quantified expression:

every in-claus(es) statifies test-expression

This quantified expression starts with the every keyword, followed by one or more in-clauses, followed by the keyword satisfies, followed by a test-expression. This expression lets you test if every item in the in-clause(s) satisfies the test expression.

Here are a few examples. This expression is true if every one of the <planet> elements in a document has a <name> child element:

every $planet in //planet satisfies $planet/name

As with the some expression, you can either test for the existence of an item this way, or you can test a logical condition. This every expression tests whether planet's <day> value is greater than or equal to one:

every $planet in //planet satisfies ($planet/day ge 1)

And you can also use multiple in-clauses with the every expression, just as you can with some, as in this example:

every $operand1 in (4, 5, 6), $operand2 in (7, 8, 9)
     satisfies $operand1 * $operand2 > 27

You can see an example where we're using every in an XSLT 2.0 stylesheet in ch08_04.xsl (Listing 8.4). In this case, we're testing three temperatures to see if they're all above 72, and if so, we'll display the message “Too hot”.

<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xsl:variable name="t1" select="80" />
<xsl:variable name="t2" select="90" />
<xsl:variable name="t3" select="100" />

    <xsl:template match="/">
        <xsl:value-of select="if (every $temperature in ($t1, $t2, $t3)
            satisfies $temperature > 72) then 'Too hot' else 'OK'"/>
    </xsl:template>
</xsl:stylesheet>

Here's the result:

<?xml version="1.0" encoding="UTF-8"?>
Too hot

The instance of operator is a Boolean operator that lets you test the type of an operand. Here's how you use it in an expression, where operand2 is a simple or complex type:

operand1 instance of operand2

This expression returns true if operand1 is of the data type operand2, and false otherwise. The type you give in operand2 can be fairly general—it can be an atomic type like xs:integer, a kind test like element() or node(), the keyword empty, or an empty sequence like this: (). It can also be the xdt:anyAtomicType type, which, as noted in Chapter 7, is an abstract type that you can't create variables of directly. If you use the xdt:anyAtomicType type with the instance of operator, you're saying that you're testing for any of the atomic types.

Using the instance of expression, you can test the data type of various items; for example, this expression returns true because 26 is an integer:

26 instance of xs:integer

Similarly, if $variable contains an integer value, this expression will return true:

$variable instance of xs:integer

Here's an example that checks if 3.1415 is of type xs:decimal:

3.1415 instance of xs:decimal

Here's an example that lets you test the context item to see if it's an element:

. instance of element()

Instance of is very useful when you are working with schema-validated nodes and need to examine their runtime type.

Because XPath 2.0 implements strong typing, it's sometimes necessary to convert values from one data type to another. You can use a cast expression to change an item's data type to another data type. You can use a cast expression like this:

source cast as target-type

Here, source is cast to a new data type, the target-type. In this case, the data type of source is actually changed to the target-type, if that cast is possible.

Here are a few examples showing how to use cast:

"2004-09-02" cast as xs:date
$variable cast as xs:integer
$temperature cast as xs:decimal

When can you use cast? Here's the list:

These rules can get pretty involved—how can you be sure the cast you're about to attempt is legal? Luckily, there's a fairly easy answer to that—you can use a castable expression to check if a cast is legal.

The castable expression lets you test if an item may be cast to a specific type, and it returns a true/false answer. Here's how you use this expression:

source castable as target-type

This expression is true if source may be cast to target-type. Here's an example where we're checking whether $fruit may be cast to the type apple, and if not, whether it can be cast to the type orange:

if ($fruit castable as apple)
then $fruit cast as apple
else if ($fruit castable as orange)
then $fruit cast as orange
else $fruit cast as xs:string

The treat expression is much like the cast expression, except that, unlike cast, it doesn't change the type of its operand. It acts like an assertion, checking the type of an expression. Here's how you use the treat operator in an expression:

source treat as target-type

This expression asserts that source is of the target-type data type. Otherwise, this expression returns an error.

Here's an example. In this case, the original type of $number might be number. Say that another type, ZIP, is derived from that type; in that case, this expression will be of the ZIP type when evaluated:

$number treat as ZIP

This expression also succeeds if the type of $number is ZIP. In other words, the treat expression acts much like an assertion, which succeeds if $number is of type ZIP or of a type derived from ZIP.