Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
This is an excerpt from
Chapter 4 of the New Riders
book called
Inside XSLT written by Steven Holzner.
PLEASE NOTE: To work with the XSLT and XPath in this
document TopXML recommends you use the demo version of Xselerator
XSL Editor
Everything you've done in this book so far has been fairly
straightforward, except for one thing: match patterns, which have
been a little mysterious. We've used various match patterns, such
as "/PLANETS" in <xsl:template> elements, without offering a
lot of systematic explanation on how these patterns really work, as
in this case:
<xsl:template match="/PLANETS">
<HTML>
<HEAD>
<TITLE>
The Planets Table
</TITLE>
</HEAD>
<BODY>
.
.
.
</BODY>
</HTML>
</xsl:template>
This chapter is going to provide all you need to know to create
match patterns in XSLT. You use match patterns in the
<xsl:template>, <xsl:key>, and <xsl:number>
elements; we've been working with <xsl:template> from the
beginning of the book, and you're going to see <xsl:key> in
Chapter 9 and <xsl:number> in Chapter 5. In particular, you
use the match attribute of <xsl:template> and
<xsl:key>, and the count and from attributes of
<xsl:number>, to match patterns.
You can also use match patterns in the select attribute of
elements such as <xsl:apply-templates>, <xsl:value-of>,
<xsl:for-each>, and <xsl:copy-of>. Here's one important
thing you need to know, however: The select attribute of these
elements is more powerful than the match, count, and from
attributes of <xsl:template>, <xsl:key>, and
<xsl:number>, because you can use full XPath expressions, not
just match patterns in select.
Match patterns are a subset of XPath expressions that is,
all match patterns are valid XPath expressions, but not all XPath
expressions are match patterns. The only XPath expressions that can
be patterns are those that return a node set (even a node set with
one node) and that use paths that specify only child or attribute
nodes.
Match patterns are defined in the XSLT recommendation itself,
whereas XPath expressions are defined in the XPath recommendation
(www.w3.org/TR/xpath); however, the two are compatible because all
match patterns are also XPath expressions.
Chapter 7 shows how to create full XPath expressions. You can
use full XPath expressions in XSLT in the following places: in the
select attribute of the <xsl:apply-templates>,
<xsl:value-of>, <xsl:for-each>, <xsl:param>,
<xsl:variable>, <xsl:wit-param>, <xsl:copy-of>,
and <xsl:sort> elements; in attribute value templates; in the
test attribute of <xsl:if> and <xsl:when> elements; in
the value attribute of <xsl:number>; and in the predicates of
match patterns.
To make things just a little more confusing, however, it turns
out that you actually can use XPath expressions in a
special, optional part (and only this part) of match patterns: the
predicate. As you're going to see in this chapter,
predicates are XPath expressions that evaluate to either true/false
values or numbers, which you enclose in brackets, [ and ]. For
example, the pattern PLANET[NAME="Venus"] matches the
<PLANET> children of the context node that have <NAME>
children with text equal to "Venus." The expressions inside the [
and ] are true XPath expressions with some restrictions that you'll
see in this chapter.
There is no question that writing match patterns takes some
experience, so I include many examples in this chapter.
Microsoft supports match patterns with its MSXML3 XML processor,
but there's one thing you should know: Microsoft also supports a
great deal of non-standard, non-W3C syntax in its match patterns.
I'm going to stick to the official, W3C, version in this chapter,
and if you happen to read Microsoft documentation on match
patterns, keep in mind that much of what you read is
Microsoft-only.
You can use the / step operator to separate element names when
you want to refer to a child of a particular node. For example, say
that you want to create a rule that applies to only those
<NAME> elements that are children of <PLANET> elements.
In that case, you can match the expression "PLANET/NAME". Here's a
rule surrounds the text of such elements in a <H3> HTML
element:
<xsl:template match="PLANET/NAME">
<H3>
<xsl:value-of
select="."/>
</H3>
</xsl:template>
You can also use the * character as a wildcard, standing for any
element. (* can match only elements, although note that the pattern
@* can match any attribute.) For example, the following rule
applies to all <NAME> elements that are grandchildren
of <PLANET> elements:
In the preceding section, I used the expression "PLANET/NAME" to
match all <NAME> elements that are direct children of
<PLANET> elements, and the expression "PLANET/*/NAME" to
match all <NAME> elements that are grandchildren of
<PLANET> elements. However, there's an easier way to perform
both matches: just use the expression "PLANET//NAME", which matches
all <NAME> elements that are inside <PLANET> elements,
no matter how many levels deep (the matched elements are called
descendants of the <PLANET> element). In other words,
"PLANET//NAME" matches "PLANET/NAME", "PLANET/*/NAME",
"PLANET/*/*/NAME", and so on:
As Chapter 3 showed, you can match attributes if you preface
their names with an @. You've already worked with the UNITS
attribute that most of the children of <PLANET> elements
support:
This is an excerpt from
Chapter 4 of the 