（一）

题记：某年某月和某同时落难的朋友去求某一个官僚；到官僚家门口碰上时他或许正要出去或许看见我们了就不进门了，直接把我们送到了街上。还有一次，求另外一个官僚办个手续，到了他家的院子，没让进屋却嘴里咕隆着说“坐下”。

任何一条河，都是弯弯曲曲的。河边千种风景，其实都是一样的。哪个湾里的水不是因为冲不破太厚、太高的障碍才拐弯的。拐过去了，就算是有流动的方向了；其实前面的弯还急着呢！
那一帮子招呼客人在院里坐下、把客人从门口接着直接送到大街上的人，连大河湾都不是，他们当时只是一个旋涡，自己转的欢，其实根本就不知道能不能流出去。

（二）

题记：同一时代同一情景，求官办事，其实就是要一碗饭吃，没有任何结果，跟乞丐一般过了一年。

    生意人老师召集客户学员到宽敞明亮的大厅“上课”，言谈优雅举止文明，绝对传道授业解惑的姿态，真的很像老师。

    这个角落很精彩，哪个旮旯可无奈？

    还在什么地方读到过这么一句话，“The first half of life is spent in longing for the second and the second half in regretting the first.”（前半生期待，后半生后悔。）细细斟酌，和上面一句话还是一个道理：无奈花落去，空叹秋雨来。

    或许人生真是如此可悲，而我等芸芸必死众生竟然体会不到这种可悲。若非哲人指点，或许大千世界能把自己及其同类看得如此透彻的人真是寥寥无几。庆幸自己明了此理的同时，我又不由自主地问道：如能超脱否？

    我的答案是：否！人之所以擅于总结自己，就是因为人自封为万生之灵，不知万物亦有别样的灵气，更体会不到这种灵气的存在。人所有的品质世间万物未必没有。把一个人和一根草同时埋没在地下，就能检验出谁更具有“灵气”。

    人的思想情感，只是一种客观存在，无论是后悔、恐惧还是欣喜、狂妄。怎么表现都是非常正常的。只要像一根埋在地下的草根一样，努力寻找出头的方向就可以了。

    一个屡战屡败，或者说屡败屡战的将军，未必没有这种怨悔和感叹，只是他从未停止寻找出头之地的这个过程。

Axis child:: 可以省略,因为它是默认axis。

Axis attribute:: can be abbreviatet to @.

Axis attribute::可以缩略为@。

// is short for /descendant-or-self::, . is short for self:: and .. is short for parent::.

// 是/descendant-or-self::的缩略；.是self::的缩略；..是parent::的缩略。

以下是示例文件。

一、xml文件

<?xml version="1.0"?> 
<xslTutorial > 
 <AAA id='a1' pos='start'> 
  <BBB  id='b1'/> 
  <BBB  id='b2'/> 
 </AAA> 
 <AAA  id='a2'> 
  <BBB  id='b3'/> 
  <BBB  id='b4'/> 
  <CCC  id='c1'> 
    <CCC  id='c2'/> 
  </CCC> 
  <BBB  id='b5'> 
    <CCC  id='c3'/> 
  </BBB> 
 </AAA> 
</xslTutorial>

二、xslStylesheet 1

<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> 
<xsl:template match="AAA"> 
 
<H3><xsl:value-of select="name()"/> 
<xsl:text> </xsl:text> 
<xsl:value-of select="@id"/></H3> 
<TABLE border="1"> 
<TR><TH>full</TH><TH>abbreviated</TH></TR> 
<TR><TD> 
<xsl:text> child::BBB/attribute::id</xsl:text> 
</TD><TD> 
<xsl:text> BBB/@id</xsl:text> 
</TD></TR> 
<TR><TD> 
<xsl:value-of select="child::BBB/attribute::id"/> 
</TD><TD> 
<xsl:value-of select="BBB/@id"/> 
</TD></TR> 
</TABLE>

</xsl:template> 
</xsl:stylesheet> 

HTML output 1

<H3>AAA a1</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>child::BBB/attribute::id</TD> 
<TD>BBB/@id</TD></TR> 
<TR> 
<TD>b1</TD> 
<TD>b1</TD></TR></TABLE> 
<H3>AAA a2</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>child::BBB/attribute::id</TD> 
<TD>BBB/@id</TD></TR> 
<TR> 
<TD>b3</TD> 
<TD>b3</TD></TR></TABLE> 

OUTPUT 1

AAA a1

full	abbreviated
child::BBB/attribute::id	BBB/@id
b1	b1

AAA a2

full	abbreviated
child::BBB/attribute::id	BBB/@id
b3	b3

 

三、xslStylesheet2

<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> 
<xsl:template match="BBB"> 
 
<H3><xsl:value-of select="name()"/> 
<xsl:text> </xsl:text> 
<xsl:value-of select="@id"/></H3> 
<TABLE border="1"> 
<TR><TH>full</TH><TH>abbreviated</TH></TR> 
<TR><TD> 
<xsl:text> parent::*/attribute::id</xsl:text> 
</TD><TD> 
<xsl:text> ../@id</xsl:text> 
</TD></TR> 
<TR><TD> 
<xsl:value-of select="parent::*/attribute::id"/> 
</TD><TD> 
<xsl:value-of select="../@id"/> 
</TD></TR> 
</TABLE>
 
</xsl:template> 
</xsl:stylesheet> 

HTML output 2

<H3>BBB b1</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>parent::*/attribute::id</TD> 
<TD>../@id</TD></TR> 
<TR> 
<TD>a1</TD> 
<TD>a1</TD></TR></TABLE> 
<H3>BBB b2</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>parent::*/attribute::id</TD> 
<TD>../@id</TD></TR> 
<TR> 
<TD>a1</TD> 
<TD>a1</TD></TR></TABLE> 
<H3>BBB b3</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>parent::*/attribute::id</TD> 
<TD>../@id</TD></TR> 
<TR> 
<TD>a2</TD> 
<TD>a2</TD></TR></TABLE> 
<H3>BBB b4</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>parent::*/attribute::id</TD> 
<TD>../@id</TD></TR> 
<TR> 
<TD>a2</TD> 
<TD>a2</TD></TR></TABLE> 
<H3>BBB b5</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>parent::*/attribute::id</TD> 
<TD>../@id</TD></TR> 
<TR> 
<TD>a2</TD> 
<TD>a2</TD></TR></TABLE> 
 

OUTPUT 2

BBB b1

full	abbreviated
parent::*/attribute::id	../@id
a1	a1

BBB b2

full	abbreviated
parent::*/attribute::id	../@id
a1	a1

BBB b3

full	abbreviated
parent::*/attribute::id	../@id
a2	a2

BBB b4

full	abbreviated
parent::*/attribute::id	../@id
a2	a2

BBB b5

full	abbreviated
parent::*/attribute::id	../@id
a2	a2

四、XSL stylesheet 3

<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'> 
 
<xsl:template match="CCC"> 
 
<H3><xsl:value-of select="name()"/> 
<xsl:text> </xsl:text> 
<xsl:value-of select="@id"/></H3> 
<TABLE border="1"> 
<TR><TH>full</TH><TH>abbreviated</TH></TR> 
<TR><TD> 
<xsl:text> name(/descendant-or-self::*)</xsl:text> 
</TD><TD> 
<xsl:text> name(//*)</xsl:text> 
</TD></TR> 
<TR><TD> 
<xsl:value-of select="name(/descendant-or-self::*)"/> 
</TD><TD> 
<xsl:value-of select="name(//*)"/> 
</TD></TR> 
</TABLE> 
 
<xsl:apply-templates/ > 
</xsl:template> 
</xsl:stylesheet> 

HTML output 3

<H3>CCC c1</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>name(/descendant-or-self::*)</TD> 
<TD>name(//*)</TD></TR> 
<TR> 
<TD>xslTutorial</TD> 
<TD>xslTutorial</TD></TR></TABLE> 
<H3>CCC c2</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>name(/descendant-or-self::*)</TD> 
<TD>name(//*)</TD></TR> 
<TR> 
<TD>xslTutorial</TD> 
<TD>xslTutorial</TD></TR></TABLE> 
<H3>CCC c3</H3> 
<TABLE border="1"> 
<TR> 
<TH>full</TH> 
<TH>abbreviated</TH></TR> 
<TR> 
<TD>name(/descendant-or-self::*)</TD> 
<TD>name(//*)</TD></TR> 
<TR> 
<TD>xslTutorial</TD> 
<TD>xslTutorial</TD></TR></TABLE> 

OUTPUT 3

CCC c1

full	abbreviated
name(/descendant-or-self::*)	name(//*)
xslTutorial	xslTutorial

CCC c2

full	abbreviated
name(/descendant-or-self::*)	name(//*)
xslTutorial	xslTutorial

CCC c3

full	abbreviated
name(/descendant-or-self::*)	name(//*)
xslTutorial	xslTutorial

Beyond the Basics

Until now, the discussion has targeted single nodes wherever possible. In fact, the focus has been on how to avoid selections that yield more than one node. Although this information is very useful to get you started, it really limits your capabilities. Without creating complex expressions, you can already perform many tasks with some of the basic functionality XPath provides.

Using a Wildcard

Wildcard characters are common in most search-oriented functions and languages. XPath has only one wildcard character: *. You can use it only to match entire names of elements or attributes, so the expression a* does not match all elements starting with the letter a. This expression generates an error instead. Wildcards are useful when you want to drill deeper into the source XML, and the names of certain nodes (particularly parent nodes) don't matter. Listing 3.14 shows how to use a wildcard.

Listing 3.14 Stylesheet Using a Wildcard

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/menu/*/dish">
6:   -<xsl:value-of select="text()" />
7:  </xsl:template>
8:
9: </xsl:stylesheet>

Line 5 in Listing 3.14 uses a wildcard character, so it doesn't matter whether the matched dish element is a child element of the appetizers, entrees, or desserts element. Line 6 just shows the value of the matched dish element. Listing 3.15 shows the result.

Listing 3.15 Result from Applying Listing 3.14 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>

   Crab Cakes

   Jumbo Prawns

   Smoked Salmon and Avocado Quesadilla

   Caesar Salad

   Grilled Salmon

   Seafood Pasta

   Linguini al Pesto

   Rack of Lamb

   Ribs and Wings

   Dame Blanche

   Chocolat Mousse

   Banana Split

In Listing 3.15, the result yields all the dish nodes, not just those that are child nodes of a particular node.

You can use this technique in all kinds of situations. Say that you've created a whitepaper or book using an XML document. Using a wildcard, you can select all the chapter and section headers to create a table of contents. If you don't want to get all the nodes, using just the wildcard doesn't solve your problem. However, just as with the path expressions you saw earlier, you can use predicates to refine the expression. That way, you have more control over what the wildcard actually matches. A simple example is shown in Listing 3.16.

Listing 3.16 Stylesheet Using Wildcards and Predicates

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/*[3]/dish[2]" />
8:   Price: <xsl:value-of select="/menu/*[3]/dish[2]/@*[2]" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>

Listing 3.16 yields the same result as Listing 3.12; the result is shown in Listing 3.13. Instead of addressing nodes by name, line 8 in Listing 3.16 uses several wildcards aided by position predicates. The desserts element is the third child element of the menu element. The /menu/*[3] section of the path expression tells the processor to take the third child element of the menu element, with no regard to the name of that element. That expression yields the desserts element, just as if it had been named. The attribute chosen is also based on a wildcard. In this case, the expression tells the processor to take the second attribute of the dish element, which is, of course, the price attribute.

注：Listing 3.16中的以下两行

7:   <xsl:value-of select="/menu/*[3]/dish[2]" />
8:   Price: <xsl:value-of select="/menu/*[3]/dish[2]/@*[2]" />

和Listing 3.12中的以下两行

7:   <xsl:value-of select="/menu/desserts/dish[2]" />
8:   Price: <xsl:value-of select="/menu/desserts/dish[2]/@price" />

所产生的实际效果一样。

结论：|直接用名称标示一个节点的路径| 和 |采用通配符加谓词说明的方式来标示一个节点的路径| ， 效果是一样的。

So far, you've learned only about elements. But what about attributes? Earlier, I said that elements and attributes don't differ very much, so you might expect that you can address them in the same way, as Listing 3.10 tries to do.

Listing 3.10 Stylesheet Trying to Select Attributes

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/desserts/dish[2]" />
8:   Price: <xsl:value-of select="/menu/desserts/dish[2]/price" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>

Line 8 in Listing 3.10 tries to get the value of the price attribute of a dish element. That this approach doesn't work is obvious from the result in Listing 3.11.

Listing 3.11 Result from Applying Listing 3.10 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>
   Dessert of the Day:
   Chocolat Mousse
   Price:

The value-of element in Listing 3.10 doesn't yield a result. A gap appears in the result because no element matches the select expression. That is as it should be, because no price element exists. The dish element does, however, have a price attribute, which is what Listing 3.10 is supposed to select. What's wrong?

Nothing is wrong. You just need to tell the processor that it needs to match an attribute, not an element. You can tell the processor that you're looking for an attribute by adding the @ character in front of the name. So, if line 8 in Listing 3.10 is supposed to point to an attribute, the path expression should be /menu/desserts/dish[2]/@price, as shown in Listing 3.12. The result in Listing 3.13 is now correct.

Listing 3.12 Stylesheet Correctly Selecting an Attribute

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/desserts/dish[2]" />
8:   Price: <xsl:value-of select="/menu/desserts/dish[2]/@price" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>

Listing 3.13 Result from Applying Listing 3.12 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>
   Dessert of the Day:
   Chocolat Mousse
   Price: 5.95

Listing 3.12 produces the desired result. Because attributes don't have any child elements, you also know that no side effects will occur. The value of the attribute is always text.

NOTE

Attributes can have data types, but all are based on the text value. Data types will be thoroughly discussed on Day 10, "Working with Data Types."

Because attributes don't have side effects, they are much easier to work with. Also, because all attributes of an element need to have a different name, you have no trouble with matching multiple attributes (and getting only the value of the first). The only way you can get multiple attributes is to start working with selections based on a wildcard character.

Another point to consider is that attributes take less space in a document than elements. Elements have begin and end tags; an attribute doesn't need these tags. Because attributes have only a text value, a parser or processor can deal with them more quickly because it doesn't have to check for child elements. This is likely to have a positive effect on performance.

注：一个元素所有的属性名称都不同，所以匹配属性时不存在像匹配元素时出现的问题，即，仅获得第一个元素的值。
    元素有开始和结束标签，而属性没有，即，属性占有的文件空间小。因为属性只有一个值，解析器不需要检查它是否含有子元素，因此解析时更快。这好像是实际效应方面的一个优点。

（我的体会：以前在什么地方看到的资料说，能处理成元素的尽量少用属性。这是以方便数据的自述性为目的的，因为，元素可以随意扩展，而属性不可以。现在看来，有些本来无需扩展的信息，没有必要做成元素，用属性标示可能更好。应该说，做程序的人更有体会：处理属性值比处理元素的数据速度要快一点。）

The problem with the code shown so far is that it acts on an element or a set of elements. Within the set of elements (such as the dish elements), no one node is singled out. If you also address a dish node instead of matching it with a template, a reasonable assumption would be that you will get the value of a single dish node. Listing 3.6 tests this assumption.

Listing 3.6 Stylesheet Getting the Value of a dish Element

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   <xsl:apply-templates />
7:  </xsl:template>
8:
9:  <xsl:template match="/menu/appetizers" />
10:
11:  <xsl:template match="/menu/entrees">
12:   <xsl:value-of select="dish" />
13:  </xsl:template>
14:
15:  <xsl:template match="/menu/desserts" />
16:
17: </xsl:stylesheet>

In Listing 3.6, the template on line 11 matching the entrees element selects only the value of a dish node on line 12. Note that, compared to Listing 3.4, there is no template matching the dish element. The result for Listing 3.6 is shown in Listing 3.7.

Listing 3.7 Result from Applying Listing 3.6 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>

 Grilled SalmonIn

Listing 3.7, the assumption made for Listing 3.6 is correct. Getting the value of a dish node yields the value of exactly one dish node. But what happened to the other nodes? After all, the xsl:value-of element matches dish nodes, so it, in fact, matches a node-set. The fact that you get a single value is again a result of the default behavior of XSLT. If a node-set matches a xsl:value-of selection, only the value of the first element in the node-set is used. The first element is the one that comes first in the source XML, according to the selection—in this case, the Grilled Salmon.

注：在以上Listing 3.6中的

11:  <xsl:template match="/menu/entrees">
12:   <xsl:value-of select="dish" />
13:  </xsl:template>

这三行获取的只是一个dish的值，即/menu/entrees的第一个子元素dish。实际上，<xsl:value-of select="dish" />选取的是dish的元素集，至于为什么只显示一个dish，这是xslt的默认规则。

（我的体会：用template来定义dish和直接用xsl::value-of select=“dish”，效果是不一样的。在UnderstandingXpath01的Listing3.4中的这三行

Now a new question arises: How do you specifically select another element in the node-set? Fortunately, you can just specify the number of the element you want to select. This, however, deviates from the path notation you are familiar with from Web sites. You need to place the number of the element you want to select between square brackets, [ and ]. Hence, you select the third dish element like this:

<xsl:value-of select="dish[3]" />

NOTE

In many programming languages, a list of elements is numbered from 0, so element number 3 is actually the fourth element in the list. XSLT numbers a list starting with 1, so element number 3 is the third element.

The value between the square brackets is called a predicate, which is a literal or expression that determines whether a certain node should be included in the selection.

Note that the preceding example uses relative addressing, which means that the selection is done based on the current location. If that is the entrees element, the third dish element in the entrees element is selected. If the current node has no child elements named dish, the value is empty.

Because predicates can be expressions, they can become quite complex, testing whether an element conforms to certain criteria. As I said at the beginning of this section, I'll discuss more complex expressions later in this book. The object now is to make you familiar with the building blocks, so let's proceed with an example based on what you've seen so far. The example in Listing 3.8 creates a menu of the day from the sample XML in Listing 3.1.

Listing 3.8 Stylesheet Creating "Today's Menu"

1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Today's Menu
7:    <xsl:value-of select="/menu/appetizers/dish[2]" />
8:    <xsl:value-of select="/menu/entrees/dish[3]" />
9:    <xsl:value-of select="/menu/desserts/dish[1]" />
10:  </xsl:template>
11:
12: </xsl:stylesheet>

Listing 3.8 has only one template on line 5, matching the root element. This template displays the values for different elements in Listing 3.1 using absolute addressing and number predicates. Line 7 selects the second dish element in the appetizers element; line 8, the third dish element in the entrees element; and line 9, the first dish element in the desserts element. Listing 3.9 shows the result.

Listing 3.9 Result from Applying Listing 3.8 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>

   Today's Menu
    Jumbo Prawns
    Linguini al Pesto
    Dame Blanche

Listing 3.8 contains only a template matching the root of the XML source. The rest of the stylesheet's functionality utilizes absolute addressing to get the wanted values. As you can see, this yields a list of dishes that form today's menu.

Earlier, you learned about the current node. After a template is fired, a certain node is considered the current node. A path expression doesn't contain a current node, but it does consist of context nodes. A context node is a part of an expression that operates on a certain node.

The predicates used in Listing 3.8 operate on the context node—in this case, the dish node. At one point or another, each part of the path's expression is the context node. It, however, is relevant only when you're working with predicates in a path expression. You can have predicates at several stages within the path expression, in which case the context node is the node that the predicate operates on.

You must realize that if no match occurs, nothing happens. This is also the case if a predicate holds a number for which no element exists. In that case, the number is just ignored. You don't see an error message or anything telling you that an element is missing. The clue is not that an element is missing, but rather that no element matches that particular rule, so the rule is never applied.

注：以上片段所说的predicate在这个阶段暂时还可以理解，不过不敢说理解透彻。遇到问题的时候还得回过头来再学习。
　

XSLT wouldn't work if it didn't have some kind of mechanism to match and select nodes and act on them. You need to be able to express which node or nodes should match. This is what XPath expressions are for. XPath is the language you use to specify which node or nodes you want to work with. Expressions in XPath can be very simple, pointing to a specific location within a document tree using absolute addressing. You can, however, make selections based on very complex rules. As you work your way through this book, you will learn to create more and more complex expressions. But, of course, you need to start simple.

Selecting Elements

If you're familiar with addresses on the World Wide Web, the most basic XPath expressions are easy to understand. A Web site is a hierarchy of files, just like an XML document is a hierarchy of elements. If you visit a Web site, you specify its root with the name of the Web site. For example, http://www.somesite.com points to the root or home page of the Web site. This is the same as http://www.somesite.com/, which is actually more accurate. What comes after this part of the address specifies where in the hierarchy of the site you want to be. So, http://www.somesite.com/menu/entrees points to the index file in the entrees directory, which is a child of the menu directory, which is a child of the root directory. The /menu/entrees path is especially interesting. It uniquely identifies a location within the Web site hierarchy, as shown in Figure 3.4.

Figure 3.4 Web site hierarchy.

Figure 3.4 shows part of the hierarchy for the Web site. Notice that /menu/entrees uniquely identifies the entrees node in the tree. If you want to select the desserts node, you change to /menu/desserts. Now look at Listing 3.1.

Listing 3.1 Menu in XML Corresponding to Figure 3.4

1: <?xml version="1.0" encoding="UTF-8"?>

2: <menu>

3:  <appetizers title="Work up an Appetite">

4:   <dish id="1" price="8.95">Crab Cakes</dish>

5:   <dish id="2" price="9.95">Jumbo Prawns</dish>

6:   <dish id="3" price="10.95">Smoked Salmon and Avocado Quesadilla</dish>

7:   <dish id="4" price="6.95">Caesar Salad</dish>

8:  </appetizers>

9:  <entrees title="Chow Time!">

10:   <dish id="5" price="19.95">Grilled Salmon</dish>

11:   <dish id="6" price="17.95">Seafood Pasta</dish>

12:   <dish id="7" price="16.95">Linguini al Pesto</dish>

13:   <dish id="8" price="18.95">Rack of Lamb</dish>

14:   <dish id="9" price="16.95">Ribs and Wings</dish>

15:  </entrees>

16:  <desserts title="To Top It Off">

17:   <dish id="10" price="6.95">Dame Blanche</dish>

18:   <dish id="11" price="5.95">Chocolat Mousse</dish>

19:   <dish id="12" price="6.95">Banana Split</dish>

20:  </desserts>

21: </menu>

NOTE

You can download the sample listings in this lesson from the publisher's Web site.

The XML in Listing 3.1 has the same tree structure as that of the Web site depicted in Figure 3.4. So, just like in the Web site, /menu/entrees points to the entrees element in the XML document. Pointing to a certain node in an XML document with XPath is, as you can see, very simple. It is based on principles that you have probably used before, so they'll be familiar to you, even though you've never worked with XPath before. To see how this approach really works, look at Listing 3.2.

Listing 3.2 Stylesheet Selecting the entrees Node from Listing 3.1

1: <?xml version="1.0" encoding="UTF-8"?>

2: <xsl:stylesheet version="1.0"

3: xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

4:

5: <xsl:template match="/">

6: <xsl:value-of select="/menu/entrees" />

7: </xsl:template>

8:

9: </xsl:stylesheet>

The template on line 5 matches the root element of the source document. The value retrieved on line 6 is selected using the expression /menu/entrees, which matched the entrees element that is the child element of the root element menu. The result from applying Listing 3.2 to Listing 3.1 is shown in Listing 3.3.

注：第5行匹配根元素。第6行利用表达式/menu/entrees检索到的是与根元素menu的子元素entrees。

Listing 3.3 Result from Applying Listing 3.2 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?> Grilled Salmon Seafood Pasta Linguini al Pesto Rack of Lamb Ribs and Wings

NOTE

Be aware that the preceding sample was run with the Saxon processor. If you use another processor, the result might be slightly different. MSXSL generates UTF-16 output by default, so the result when using MSXSL will have spaces between each letter.

Listing 3.3 shows the value of all the child nodes of the entrees node. If you remember yesterday's lesson, that is exactly right, as line 6 of Listing 3.2 asks for the value of the entrees node. That node's value contains all its descendant nodes. Getting its value yields the text value of the descendant elements. This scenario is a bit confusing because it looks like Listing 3.2 actually selects a node-set consisting of all the child elements of the entrees node. If the entrees node also contains a text value, you would see that this isn't true. You can, however, create an additional template to handle the dish elements, as shown in Listing 3.4.

注：Listing 3.3显示的是entrees节点的所有子节点的值。这个节点包含所有的子孙节点，获取值就是子孙节点的值。这种情况有点令人迷惑：它实际获取的是包含所有子孙节点的一个节点集。如果entrees节点本身也含有值的话，情况会变化的。让然，你可以继续用template深入到它的子节点去处理dish元素。

（我的体会：子（或孙）节点的值归属于父（或祖）节点，即，如果你不对子孙节点进一步定义的话，匹配父（或祖）节点时获得的值就是子（或孙）节点的值。这是xslt默认的规则。如果你详细定义了子节点，那么这一默认值对于相应的父（或祖）节点无效。）

Listing 3.4 Stylesheet with More Control over dish Elements

1: <?xml version="1.0" encoding="UTF-8"?>

2: <xsl:stylesheet version="1.0"

3: xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

4:

5: <xsl:template match="/">

6: <xsl:apply-templates />

7: </xsl:template>

8:

9: <xsl:template match="/menu/appetizers" />

10:

11: <xsl:template match="/menu/entrees">

12: Entrees:

13: <xsl:apply-templates />

14: </xsl:template>

15:

16: <xsl:template match="/menu/desserts" />

17:

18: <xsl:template match="dish">

19: <xsl:value-of select="text()" />

20: </xsl:template>

21:

22: </xsl:stylesheet>

In Listing 3.4, note that lines 9 and 16 effectively ignore the appetizers and desserts nodes in Listing 3.1 to keep the result small and to the point. The result of applying Listing 3.4 to Listing 3.1 is shown in Listing 3.5.

注：第9和16行实际上对于appetizers节点desserts的子节点的值不处理，因为text()值只对第11到14行中定义明确的entrees节点有效。

Listing 3.5 Result from Applying Listing 3.4 to Listing 3.1

<?xml version="1.0" encoding="utf-8"?>

  Entrees:

   Grilled Salmon

   Seafood Pasta

   Linguini al Pesto

   Rack of Lamb

   Ribs and Wings

In Listing 3.5, each dish node is now handled separately. The hyphen (-) in front of each dish shows that this is really the case. The whitespace appears, as I said before, because of the processor's default whitespace rules.

XSLT wouldn't work if it didn't have some kind of mechanism to match and select nodes and act on them. You need to be able to express which node or nodes should match. This is what XPath expressions are for. XPath is the language you use to specify which node or nodes you want to work with. Expressions in XPath can be very simple, pointing to a specific location within a document tree using absolute addressing. You can, however, make selections based on very complex rules. As you work your way through this book, you will learn to create more and more complex expressions. But, of course, you need to start simple.

Selecting Elements
If you're familiar with addresses on the World Wide Web, the most basic XPath expressions are easy to understand. A Web site is a hierarchy of files, just like an XML document is a hierarchy of elements. If you visit a Web site, you specify its root with the name of the Web site. For example, http://www.somesite.com points to the root or home page of the Web site. This is the same as http://www.somesite.com/, which is actually more accurate. What comes after this part of the address specifies where in the hierarchy of the site you want to be. So, http://www.somesite.com/menu/entrees points to the index file in the entrees directory, which is a child of the menu directory, which is a child of the root directory. The /menu/entrees path is especially interesting. It uniquely identifies a location within the Web site hierarchy, as shown in Figure 3.4.

Figure 3.4 Web site hierarchy.

Figure 3.4 shows part of the hierarchy for the Web site. Notice that /menu/entrees uniquely identifies the entrees node in the tree. If you want to select the desserts node, you change to /menu/desserts. Now look at Listing 3.1.

Listing 3.1 Menu in XML Corresponding to Figure 3.4
1: <?xml version="1.0" encoding="UTF-8"?>
2: <menu>
3:  <appetizers title="Work up an Appetite">
4:   <dish id="1" price="8.95">Crab Cakes</dish>
5:   <dish id="2" price="9.95">Jumbo Prawns</dish>
6:   <dish id="3" price="10.95">Smoked Salmon and Avocado Quesadilla</dish>
7:   <dish id="4" price="6.95">Caesar Salad</dish>
8:  </appetizers>
9:  <entrees title="Chow Time!">
10:   <dish id="5" price="19.95">Grilled Salmon</dish>
11:   <dish id="6" price="17.95">Seafood Pasta</dish>
12:   <dish id="7" price="16.95">Linguini al Pesto</dish>
13:   <dish id="8" price="18.95">Rack of Lamb</dish>
14:   <dish id="9" price="16.95">Ribs and Wings</dish>
15:  </entrees>
16:  <desserts title="To Top It Off">
17:  <dish id="10" price="6.95">Dame Blanche</dish>
18:  <dish id="11" price="5.95">Chocolat Mousse</dish>
19:  <dish id="12" price="6.95">Banana Split</dish>
20: </desserts>
21: </menu>NOTE

You can download the sample listings in this lesson from the publisher's Web site.

The XML in Listing 3.1 has the same tree structure as that of the Web site depicted in Figure 3.4. So, just like in the Web site, /menu/entrees points to the entrees element in the XML document. Pointing to a certain node in an XML document with XPath is, as you can see, very simple. It is based on principles that you have probably used before, so they'll be familiar to you, even though you've never worked with XPath before. To see how this approach really works, look at Listing 3.2.

Listing 3.2 Stylesheet Selecting the entrees Node from Listing 3.1
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   <xsl:value-of select="/menu/entrees" />
7:  </xsl:template>
8:
9: </xsl:stylesheet>The template on line 5 matches the root element of the source document. The value retrieved on line 6 is selected using the expression /menu/entrees, which matched the entrees element that is the child element of the root element menu. The result from applying Listing 3.2 to Listing 3.1 is shown in Listing 3.3.

Listing 3.3 Result from Applying Listing 3.2 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>
  Grilled Salmon
  Seafood Pasta
  Linguini al Pesto
  Rack of Lamb
  Ribs and WingsNOTE

Be aware that the preceding sample was run with the Saxon processor. If you use another processor, the result might be slightly different. MSXSL generates UTF-16 output by default, so the result when using MSXSL will have spaces between each letter.

Listing 3.3 shows the value of all the child nodes of the entrees node. If you remember yesterday's lesson, that is exactly right, as line 6 of Listing 3.2 asks for the value of the entrees node. That node's value contains all its descendant nodes. Getting its value yields the text value of the descendant elements. This scenario is a bit confusing because it looks like Listing 3.2 actually selects a node-set consisting of all the child elements of the entrees node. If the entrees node also contains a text value, you would see that this isn't true. You can, however, create an additional template to handle the dish elements, as shown in Listing 3.4.

Listing 3.4 Stylesheet with More Control over dish Elements
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   <xsl:apply-templates />
7:  </xsl:template>
8:
9:  <xsl:template match="/menu/appetizers" />
10:
11:  <xsl:template match="/menu/entrees">
12:   Entrees:
13:   <xsl:apply-templates />
14:  </xsl:template>
15:
16:  <xsl:template match="/menu/desserts" />
17:
18:  <xsl:template match="dish">
19:    <xsl:value-of select="text()" />
20:  </xsl:template>
21:
22: </xsl:stylesheet>In Listing 3.4, note that lines 9 and 16 effectively ignore the appetizers and desserts nodes in Listing 3.1 to keep the result small and to the point. The result of applying Listing 3.4 to Listing 3.1 is shown in Listing 3.5.

Listing 3.5 Result from Applying Listing 3.4 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>

   Entrees:

  Grilled Salmon

  Seafood Pasta

  Linguini al Pesto

  Rack of Lamb

  Ribs and WingsIn Listing 3.5, each dish node is now handled separately. The hyphen (-) in front of each dish shows that this is really the case. The whitespace appears, as I said before, because of the processor's default whitespace rules.

Getting the Value of a Single Element
The problem with the code shown so far is that it acts on an element or a set of elements. Within the set of elements (such as the dish elements), no one node is singled out. If you also address a dish node instead of matching it with a template, a reasonable assumption would be that you will get the value of a single dish node. Listing 3.6 tests this assumption.

Listing 3.6 Stylesheet Getting the Value of a dish Element
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   <xsl:apply-templates />
7:  </xsl:template>
8:
9:  <xsl:template match="/menu/appetizers" />
10:
11:  <xsl:template match="/menu/entrees">
12:   <xsl:value-of select="dish" />
13:  </xsl:template>
14:
15:  <xsl:template match="/menu/desserts" />
16:
17: </xsl:stylesheet>In Listing 3.6, the template on line 11 matching the entrees element selects only the value of a dish node on line 12. Note that, compared to Listing 3.4, there is no template matching the dish element. The result for Listing 3.6 is shown in Listing 3.7.

Listing 3.7 Result from Applying Listing 3.6 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>

 Grilled SalmonIn Listing 3.7, the assumption made for Listing 3.6 is correct. Getting the value of a dish node yields the value of exactly one dish node. But what happened to the other nodes? After all, the xsl:value-of element matches dish nodes, so it, in fact, matches a node-set. The fact that you get a single value is again a result of the default behavior of XSLT. If a node-set matches a xsl:value-of selection, only the value of the first element in the node-set is used. The first element is the one that comes first in the source XML, according to the selection—in this case, the Grilled Salmon.

Now a new question arises: How do you specifically select another element in the node-set? Fortunately, you can just specify the number of the element you want to select. This, however, deviates from the path notation you are familiar with from Web sites. You need to place the number of the element you want to select between square brackets, [ and ]. Hence, you select the third dish element like this:

<xsl:value-of select="dish[3]" />NOTE

In many programming languages, a list of elements is numbered from 0, so element number 3 is actually the fourth element in the list. XSLT numbers a list starting with 1, so element number 3 is the third element.

The value between the square brackets is called a predicate, which is a literal or expression that determines whether a certain node should be included in the selection.

Note that the preceding example uses relative addressing, which means that the selection is done based on the current location. If that is the entrees element, the third dish element in the entrees element is selected. If the current node has no child elements named dish, the value is empty.

Because predicates can be expressions, they can become quite complex, testing whether an element conforms to certain criteria. As I said at the beginning of this section, I'll discuss more complex expressions later in this book. The object now is to make you familiar with the building blocks, so let's proceed with an example based on what you've seen so far. The example in Listing 3.8 creates a menu of the day from the sample XML in Listing 3.1.

Listing 3.8 Stylesheet Creating "Today's Menu"
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Today's Menu
7:    <xsl:value-of select="/menu/appetizers/dish[2]" />
8:    <xsl:value-of select="/menu/entrees/dish[3]" />
9:    <xsl:value-of select="/menu/desserts/dish[1]" />
10:  </xsl:template>
11:
12: </xsl:stylesheet>Listing 3.8 has only one template on line 5, matching the root element. This template displays the values for different elements in Listing 3.1 using absolute addressing and number predicates. Line 7 selects the second dish element in the appetizers element; line 8, the third dish element in the entrees element; and line 9, the first dish element in the desserts element. Listing 3.9 shows the result.

Listing 3.9 Result from Applying Listing 3.8 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>
   Today's Menu
    Jumbo Prawns
    Linguini al Pesto
    Dame BlancheListing 3.8 contains only a template matching the root of the XML source. The rest of the stylesheet's functionality utilizes absolute addressing to get the wanted values. As you can see, this yields a list of dishes that form today's menu.

Earlier, you learned about the current node. After a template is fired, a certain node is considered the current node. A path expression doesn't contain a current node, but it does consist of context nodes. A context node is a part of an expression that operates on a certain node.

The predicates used in Listing 3.8 operate on the context node—in this case, the dish node. At one point or another, each part of the path's expression is the context node. It, however, is relevant only when you're working with predicates in a path expression. You can have predicates at several stages within the path expression, in which case the context node is the node that the predicate operates on.

You must realize that if no match occurs, nothing happens. This is also the case if a predicate holds a number for which no element exists. In that case, the number is just ignored. You don't see an error message or anything telling you that an element is missing. The clue is not that an element is missing, but rather that no element matches that particular rule, so the rule is never applied.

Selecting Attributes
So far, you've learned only about elements. But what about attributes? Earlier, I said that elements and attributes don't differ very much, so you might expect that you can address them in the same way, as Listing 3.10 tries to do.

Listing 3.10 Stylesheet Trying to Select Attributes
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/desserts/dish[2]" />
8:   Price: <xsl:value-of select="/menu/desserts/dish[2]/price" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>Line 8 in Listing 3.10 tries to get the value of the price attribute of a dish element. That this approach doesn't work is obvious from the result in Listing 3.11.

Listing 3.11 Result from Applying Listing 3.10 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>
   Dessert of the Day:
   Chocolat Mousse
   Price:The value-of element in Listing 3.10 doesn't yield a result. A gap appears in the result because no element matches the select expression. That is as it should be, because no price element exists. The dish element does, however, have a price attribute, which is what Listing 3.10 is supposed to select. What's wrong?

Nothing is wrong. You just need to tell the processor that it needs to match an attribute, not an element. You can tell the processor that you're looking for an attribute by adding the @ character in front of the name. So, if line 8 in Listing 3.10 is supposed to point to an attribute, the path expression should be /menu/desserts/dish[2]/@price, as shown in Listing 3.12. The result in Listing 3.13 is now correct.

Listing 3.12 Stylesheet Correctly Selecting an Attribute
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/desserts/dish[2]" />
8:   Price: <xsl:value-of select="/menu/desserts/dish[2]/@price" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>Listing 3.13 Result from Applying Listing 3.12 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>
   Dessert of the Day:
   Chocolat Mousse
   Price: 5.95Listing 3.12 produces the desired result. Because attributes don't have any child elements, you also know that no side effects will occur. The value of the attribute is always text.

NOTE

Attributes can have data types, but all are based on the text value. Data types will be thoroughly discussed on Day 10, "Working with Data Types."

Because attributes don't have side effects, they are much easier to work with. Also, because all attributes of an element need to have a different name, you have no trouble with matching multiple attributes (and getting only the value of the first). The only way you can get multiple attributes is to start working with selections based on a wildcard character.

Another point to consider is that attributes take less space in a document than elements. Elements have begin and end tags; an attribute doesn't need these tags. Because attributes have only a text value, a parser or processor can deal with them more quickly because it doesn't have to check for child elements. This is likely to have a positive effect on performance.

Beyond the Basics
Until now, the discussion has targeted single nodes wherever possible. In fact, the focus has been on how to avoid selections that yield more than one node. Although this information is very useful to get you started, it really limits your capabilities. Without creating complex expressions, you can already perform many tasks with some of the basic functionality XPath provides.

Using a Wildcard
Wildcard characters are common in most search-oriented functions and languages. XPath has only one wildcard character: *. You can use it only to match entire names of elements or attributes, so the expression a* does not match all elements starting with the letter a. This expression generates an error instead. Wildcards are useful when you want to drill deeper into the source XML, and the names of certain nodes (particularly parent nodes) don't matter. Listing 3.14 shows how to use a wildcard.

Listing 3.14 Stylesheet Using a Wildcard
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/menu/*/dish">
6:   -<xsl:value-of select="text()" />
7:  </xsl:template>
8:
9: </xsl:stylesheet>Line 5 in Listing 3.14 uses a wildcard character, so it doesn't matter whether the matched dish element is a child element of the appetizers, entrees, or desserts element. Line 6 just shows the value of the matched dish element. Listing 3.15 shows the result.

Listing 3.15 Result from Applying Listing 3.14 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>

   Crab Cakes

   Jumbo Prawns

   Smoked Salmon and Avocado Quesadilla

   Caesar Salad

   Grilled Salmon

   Seafood Pasta

   Linguini al Pesto

   Rack of Lamb

   Ribs and Wings

   Dame Blanche

   Chocolat Mousse

   Banana SplitIn Listing 3.15, the result yields all the dish nodes, not just those that are child nodes of a particular node.

You can use this technique in all kinds of situations. Say that you've created a whitepaper or book using an XML document. Using a wildcard, you can select all the chapter and section headers to create a table of contents. If you don't want to get all the nodes, using just the wildcard doesn't solve your problem. However, just as with the path expressions you saw earlier, you can use predicates to refine the expression. That way, you have more control over what the wildcard actually matches. A simple example is shown in Listing 3.16.

Listing 3.16 Stylesheet Using Wildcards and Predicates
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/">
6:   Dessert of the Day:
7:   <xsl:value-of select="/menu/*[3]/dish[2]" />
8:   Price: <xsl:value-of select="/menu/*[3]/dish[2]/@*[2]" />
9:  </xsl:template>
10:
11: </xsl:stylesheet>Listing 3.16 yields the same result as Listing 3.12; the result is shown in Listing 3.13. Instead of addressing nodes by name, line 8 in Listing 3.16 uses several wildcards aided by position predicates. The desserts element is the third child element of the menu element. The /menu/*[3] section of the path expression tells the processor to take the third child element of the menu element, with no regard to the name of that element. That expression yields the desserts element, just as if it had been named. The attribute chosen is also based on a wildcard. In this case, the expression tells the processor to take the second attribute of the dish element, which is, of course, the price attribute.

Working with the Document Tree
What you've seen so far is quite rigid in utilizing the XML document tree. XPath can do much more, based on location paths, which are expressions that select a node or node-set relative to the context node. A location path consists of several parts. The path expressions you've seen so far often are specific cases of location paths, starting from the root node or current node (from a matching template). Location paths can, however, appear in other instances and as part of a predicate within a path expression. One part of a location path is actually a predicate, so you can have a location path with a predicate, containing a location path containing another predicate, and so on.

Another part of a location path that you are already familiar with is called a node test, which is the part of the location path that matches a certain node or nodes. This definition is clearer with an example. Consider the following location path:

/menu/*[3]/dish[2]/@*[2]Here, menu, *, dish, and @* are node tests.

The last (or actually the first) part of a location path may not be familiar to you yet. This part, called an axis, is an expression specifying the relationship within the document tree between the selected nodes and the context node.

In the previous examples, you saw quite a few location paths. Not all of them contained axes, however. Well, they did, but the axes were included implicitly. Look at the following location path:

/menu/desserts/dishThis location path selects all the dish elements, which are child nodes of desserts nodes, which in turn are child nodes of the root element menu. If you write out that location path in full, it actually reads

/child::menu/child::desserts/child::dishThe axis and the node test are always separated by a double colon. The axis in front of the node test tells the processor where to look for a node or node-set. The node test tells the processor which nodes to actually match. Using the explicit location path isn't very useful for match templates. The location path only becomes lengthier and less readable. Also, you would not often use the child axis because it is included implicitly anyway.

Another axis you are already familiar with is the attribute axis. You are actually familiar with its shortcut, the @ character. In Listing 3.12, the following location path was used on line 8:

/menu/desserts/dish[2]/@priceYou also can write the @price selection using the attribute axis, which would yield the following location path:

/menu/desserts/dish[2]/attribute::priceAn axis that you haven't yet encountered but is quite clear is the parent axis. Yes, you guessed it: It returns the parent node of the current context. Listing 3.17 shows an example using the parent axis.

Listing 3.17 Stylesheet Using parent Axis
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/"><xsl:apply-templates /></xsl:template>
6:
7:  <xsl:template match="/menu/appetizers/dish">
8:   <xsl:value-of select="parent::*/@title" />: <xsl:value-of select="." />
9:  </xsl:template>
10:
11:  <xsl:template match="/menu/entrees" />
12:  <xsl:template match="/menu/desserts" />
13:
14: </xsl:stylesheet>Line 8 in Listing 3.17 uses the parent axis to select the title attribute of the parent element. This is the parent element of the current node, which is one of the dish elements in the appetizers element. Listing 3.18 shows the result.

Listing 3.18 Result from Applying Listing 3.17 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>

  Work up an Appetite: Crab Cakes
  Work up an Appetite: Jumbo Prawns
  Work up an Appetite: Smoked Salmon and Avocado Quesadilla
  Work up an Appetite: Caesar SaladIn Listing 3.18, the title attribute is inserted with every dish. This could also have been done with absolute addressing, but if there had been a separate template for the dish element, dishes in entrees or desserts could also match and the title would need to be different. In that case, relative addressing using the parent axis would be the only way out.

There is another way to specify any parent node. If you're familiar with the command prompt from DOS or Unix, it will look familiar. The location path

parent::*/@titlecan also be written as

../@titleThe latter example is much more compact and usable. If, however, the node test is not a wildcard, using this location path would not work. You would have to specify the parent axis explicitly, as well as the node that the node test needs to match.

Multilevel Axes
The axes discussed so far cover a single level in the XML document tree. They either go one level down, to child nodes, or one level up, to the parent node. Several axes operate on multiple levels. This does not mean, however, that such an axis returns a tree fragment because that wouldn't give added functionality. If that were the case, the parent and child axes would suffice. Each multilevel axis yields a node-set containing all the elements within that axis. The order in which the elements appear in the node-set depends on the axis. So, you can actually think of a multilevel axis as part of the XML document tree "flattened" into a set.

The best way to show you how these axes work is to go through some examples. The easiest axis to start with is ancestor, which is shown in Listing 3.19.

Listing 3.19 Stylesheet Using the Ancestor Axis
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="/menu/appetizers">
6:    <xsl:value-of select="dish[1]/ancestor::*[1]/@title" />
7:    <xsl:value-of select="dish[1]/ancestor::menu/entrees/@title" />
8:  </xsl:template>
9:
10:  <xsl:template match="/menu/entrees">
11:  <xsl:template match="/menu/desserts">
12:
13: </xsl:stylesheet>All the action occurs in Lines 6 and 7 in Listing 3.19. Both lines first select the first child node of the appetizers element named dish. At that point, this element becomes the context node. Next, the ancestor axis tells the processor it wants to act on the ancestor nodes of the context node. The ancestor nodes are appetizers and menu. On line 6, the node test consists of a wildcard and predicate—in this case, pointing to the first ancestor node in the axis, which is the parent node appetizers. On line 7, a named node test specifies that the menu element is the element needed in this particular axis. This line could also have been written as ancestor::*[2] because that is the grandparent of the context node and, as such, the second node in the axis node-set ancestor.

Listing 3.20 Result from Applying Listing 3.19 to Listing 3.1
<?xml version="1.0" encoding="utf-8"?>

    Work up an Appetite
    Chow Time!Listing 3.20 shows that Listing 3.19 first selects the title attribute of the appetizers element and then the title attribute of the entrees element.

Several more multilevel axes are available. All axes are listed in Table 3.1.

Table 3.1 Available Axes
Axis
 Description
 
Self
 The context node itself
 
child
 All child nodes of the context node
 
parent
 The parent node of the context node
 
ancestor
 All ancestor nodes of the context node
 
ancestor-or-self
 Same as ancestor, including the context node as the first node in the node-set
 
descendant
 All descendant nodes of the context node, numbered depth first (for example, child 1, grandchild 1, child 2, grandchild 2, and so on)
 
descendant-or-self
 Same as descendant, including the context node as the first node in the node-set
 
following-sibling
 All sibling nodes that succeed the context node within the document tree
 
following
 Same as following-sibling, but including their descendants, depth first (for example, sibling 1, child 1 of sibling 1, sibling 2, and so on)
 
preceding-sibling
 All sibling nodes that precede the context node within the document tree
 
preceding
 Same as preceding-sibling, but including their descendants, depth first (for example, sibling 1, child 1 of sibling 1, sibling 2, and so on)
 

Figure 3.5 shows a graphical representation of most axes in Table 3.1 to give you a better idea of what each axis listed actually selects.

Figure 3.5 Graphical representation of the axes in Table 3.1.

Something that is, strictly speaking, not an axis but fits nicely in this section is the // expression. It matches any location within the document tree. So, //dish matches any dish node within the document. Listing 3.21 shows this expression in action.

Listing 3.21 Stylesheet Using // to Get All Nodes
1: <?xml version="1.0" encoding="UTF-8"?>
2: <xsl:stylesheet version="1.0"
3:  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
4:
5:  <xsl:template match="//dish">
6:    <xsl:value-of select="text()" />
7:  </xsl:template>
8:
9: </xsl:stylesheet>Listing 3.21 yields the same result as Listing 3.14 because line 5 uses // to match all nodes in the document from which the dish nodes are selected.

A common mistake is to think that //dish[6] will yield the sixth dish element within the document. Unfortunately, because of precedence rules, this expression will yield no element at all. The processor will look for a sixth element in each of the parent contexts. Unfortunately, there is none because appetizers contains only four dish elements; entrees, only five; and desserts, only three. So how do you solve this problem? You can use parentheses to override the default precedence. Therefore, (//dish)[6] would yield the sixth element (the Seafood Pasta).

Today's lesson will focus on getting more control over the data you select. Today you will learn the following:

How the XML document tree works

What XPath is

How you can select single elements

How you can select multiple elements

How you can select attributes

Understanding the XML Document Tree
An XML document is a hierarchical structure of elements. Each element in an XML document can have zero or more child elements, which in turn have that same property. Also, each element can have zero or more attributes. No surprises so far, but it's actually significant that an XML document is structured this way. Every element and every attribute has a uniquely identifiable place within the document tree. Because all elements and attributes are uniquely identifiable, you can address a single element or attribute and get its value. Figure 3.1 clarifies this structure.

Figure 3.1 Graphical representation of a tree.

In Figure 3.1, each element in the tree is shown as a circle. Different children of an element can be distinguished because different letters identify them. As you can see, some elements have children with the same letters to identify them. This means that you can't say "Give me the value of element C," because element C can be the child element of either element B or element F. This doesn't mean, however, that you can't address this element at all; you just have to be more specific. To get the value of a specific element, you would have to say "Give me the value of element C, the child of element B, which is the child of the root element A." When you address an element in this manner, you use absolute addressing, as shown in Figure 3.1. Absolute addressing means that you specify the exact location of an element within a tree. With absolute addressing, you always specify a unique location.

Another way of addressing is relative to an element. Say that element E in Figure 3.1 is the element's starting point. If you want to address the same element as before, you can say "Give me the value of element C, the sibling element of my parent element." This type of addressing is called relative addressing, as shown in Figure 3.1. Relative addressing means that you specify the location of an element within a tree relative to the position of the current location.

With relative addressing, you don't specify a unique location within the document tree. Which element is specified by the preceding query actually depends on the starting point of the query.

What Is a Node?
Until now, I have been talking about elements and attributes. The difference between elements and attributes is not that great, however. The most important difference is that an element can have child elements; an attribute cannot. Hence, an attribute always has a single (text) value, whereas the value of an element also includes any descendant elements (and attributes).

Because elements and attributes aren't very different, they can be represented as the same thing in a diagram of the XML document tree. Element E in Figure 3.1, for example, could just as well be an attribute because it doesn't have any child elements. In fact, some people think that attributes shouldn't be used because attributes are just special cases of elements. Attributes and elements are interchangeable, as long as an element doesn't have child elements (or attributes). Because attributes are simply names with associated values, also known as name-value pairs, an element can contain only attributes that have different names. An element value, on the other hand, can contain multiple elements with the same name. This distinction is very important when you're designing XML documents, especially when they might have to change in the future.

Within the Document Object Model (DOM), as well as Extensible Stylesheet Language Transformations (XSLT, or actually XPath), the distinction between an element and attribute is so small that they are treated more or less as being the same. Several functions in DOM Level 2 work equally well on elements and attributes. The functions nodeName and nodeValue make no distinction between elements and attributes, although the result may differ based on the type of node the function is used on. Because an element and an attribute are very similar, they are referred to as a node, which is a single item that contains data within the document tree.

Current Node
On Day 2, I used the term current element tentatively. Although this concept is somewhat self-explanatory, some clarification is in order. Also, because of the similarities between elements and attributes, from now on I will use the term current node.

On Day 2, you saw that when a stylesheet processes an XML document, elements of the source XML are matched against templates in the stylesheet. What you haven't learned yet is that you can also create match expressions that match an attribute. So, actually, nodes of the source XML are matched against the templates. Each time a match occurs and a template is invoked, the node that fired the template becomes the current node, which basically is a pointer to a node within the XML tree. This pointer keeps track of which node is being processed.

NOTE

If you're working with an XSLT debugger that enables you to perform the transformation process step by step, you can see which node is the current node. The debugger keeps track of the current node and the template that is being fired and shows that information to you.

Because the current node is just a pointer to the node being processed, a template is not limited to accessing the value of that node alone. Within a template, you can use absolute addressing or relative addressing to get the value of any node in the XML document. As I said earlier, this value isn't necessarily a single value. If an element has attributes and descendant elements, they are also part of that value. Such a value is called a tree fragment, which is a part of an XML document tree, starting at a specific node. A tree fragment is itself a well-formed XML structure or document.

You already saw tree fragments in action on Day 2, when you learned about the text() function that extracts only the text value of an element. If you just specify the value of an element, the text of the element and all its descendants is written to the output. That is, in fact, the text value of the tree fragment. To get a better idea what a tree fragment is, look at Figure 3.2.

Figure 3.2 Tree fragment of node T.

Figure 3.2 is a graphical representation of a tree fragment. In this case, the tree fragment belongs to node T. This is actually the same as the value of node T.

What Is a Node-Set?
Now that you know what a node is, you probably think that a node-set isn't hard to explain. It's a set of nodes, right? Well, yes, but that's not all of it.

When you make a selection based on an expression, the expression doesn't necessarily match one node. It may match several nodes. These nodes together are called a node-set. The most common node-set is a series of an element's child nodes. Some people think this is the only kind of node-set, but it isn't. You can easily create an expression that yields a node-set with nodes in different sections of an XML document. Figure 3.3 shows an example.

Figure 3.3 Node-set containing nodes scattered throughout an XML document.

Figure 3.3 represents the node-set you would get if you were to say "Give me all nodes named B." As you can see, the node's location in the XML document tree is not relevant. Any node matching your query is part of the node-set. The node-set in Figure 3.3 is composed of several nodes. From those nodes, you have access to the tree fragment composed of that node and its descendants. If the expression targeted only attributes, the node-set would consist of only single value nodes.

Node-sets are essential in XSLT. They enable you to create a table of contents, indexes, and all sorts of other documents in which you use data that is scattered throughout an XML document. This capability enables you to create different outputs for different purposes from the same XML source document.

风起云动

天地容颜依然

时过境迁

人生情怀未变

有道是

山是山

川是川

山川江河永相连

情归情

怨归怨

情仇恩怨总纠缠

谁予我利剑

将它斩断

一边归情

一边还怨

select="text", select="/*/*/text", select="//text"大不一样

    拿到录取通知书，参加了军训，知道了9月1日正式上课，其他的事一概不理：困了就睡，睡醒就玩，饿了就吃。

    算你厉害，给我省了一万，你就这么狂！

    你小子还是嫩着呢！

    直到今天下午才准备明天上学需要的东西，一看录取通知书，才知道8月30号要到校正式办理注册手续，并且旁边有明确的文字说明，即，学校有权对过期不注册者取消入学资格。然后，才给我打电话，问我怎么办？

    能怎么办？你小子能干，明天自己到学校去看！

    真是个宝贝，让人哭笑不得！

江河不知清
岸边树倒映
花香何曾羞
只是人多情

（二）

人生本无味
山川亦无情
谁若知苦辛
定是执著人

     近日的工作颇有麻烦！

    “驴还吃烧鸡粉哩！”一个小青年指着栓在电线杆上的驴说，其他的几个一阵狂笑。

    老汉一句话也没有说，连喝带吃几大口把烧鸡粉吃完，付过钱，朝毛驴走去。

    突然，只听“啪！啪！”两声。烧鸡摊上的人顺着声音的方向看过去。只见老汉朝着毛驴的长脸又一次左右开弓，嘴里骂骂咧咧：“进城前我问过你城里有没有亲戚，你说没有！你说，给你打招呼的是你的啥亲戚？”

（注：最早听朋友的朋友讲起这个笑话。后来我把这个笑话推荐给朋友的朋友，便出现在了他的博客中。近日重温，倍感风趣，把它再搬过来。）

梦里回陇西。

窗外雪花飘，

炉边茶香溢。

（三年前听到老先生仙逝的消息，想起当年与老先生雪天炉边焙茗之情景，是夜梦游陇西，重温那段忘年之交。次日心生感慨而作。老先生三年忌日即将来临之际，谨以此文为祭。）

    其实，知道了大概的原理，该转换一下角色了。即使我把毕生的精力都花在这方面，不一定能做出一个令人满意的东西。我的主要目的就是通过学习了解一下规划与执行之间有多大的出入，不是直接参与其中。是该找人做的时候了。我再这么做下去，无异于浪费时间。

    来杯茶，抽支烟，下盘棋。然后轻轻松松的睡觉。

    三局两胜的比赛，中国对第一局赢得轻松，想必第二局不会有太大的问题吧。谁知我看到的时候第二局已经是中国队已经落后对手六七分，而对手已经离局点仅有两三分了。

    谁都有过这样的境遇：已经胜过对方一筹，何必过多在乎此筹？尽力吧！再胜一筹当然好，即使输了，不过才是个平手吗？

    这正是要命的错误。我们一生中的很多失败就是由这种心理导致的。不拼此筹，气势上已经输了。即使再给你一个机会，你也不一定能取胜于对手。

    中国队轻易放弃本可以再拼一番的第二局，这是一个严重的错误。如果第二局就使劲拼，谁也说不清会不会有咸鸭翻身的机会。一旦有，那就是终结对手。即使让对手拿下，也让他们心理上发怵。第二局落后时的拼和第三局落后的时候的拼，效果截然不同：前者是在要对手的命，后者只是再和对手争胜负。

    拼搏是人生的主题曲。有些人唱得好，只是因为唱对了时机。错过了时机，无论如何拼搏，多半是徒劳的。