Hi there! Welcome to our blog. Don't forget to sign up for our free RSS feed. We Triple Dog Dare Ya! And thanks for visiting!

Without XPath, you really can’t control XSLT (and other XML technologies) with any kind of granularity. To draw an analogy, working with XML technologies without a knowledge of XPath is like trying to understand databases without knowing SQL.

Just like SQL, XPath is a query language, but its syntax is more closely related, in some ways, to regular expressions. At the same time, it’s also a syntax that defines structural parts of an XML document in notation that is similar to file paths.

For example, if you were working on a UNIX machine and I told you to open up the following file, you’d know to look in your current working directory:

File.xml

However, if I told you to look in:

../File.xml

You’d know to look in the directory “above” your current working directory.  Similarly, if I told you to look in:

/home/File.xml

You’d go all the way to the root of your directory hierarchy and then look in the /home directory for the appropriate file. We all know, instinctively that these three file path notations could be pointing to the same file or to three completely different files, depending on our current working directory.

XPath works in much the same way. You can always grab the root element of a document like this:

<xsl:template match="/">

With XPath, you could match all elements that share the same name:

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

Or you could match only certain elements, depending on their context within an XML file:

<xsl:template match="memo/title"> 

<!—- only grabs title elements belonging to a memo  element -->

You can retrieve elements using the “.” and “..” notation as well. Predictably, “.” is shorthand for “the current node” and “..” is shorthand for “nodes that are children of this node’s grandparent”.

If XPath were just good at retrieving nodes based on a path, that would be terrific. However, XPath also allows us to be more discriminating with our searches. For example, we may want to retrieve only those elements that have a certain attribute value set:

<xsl:template match="title[@priority=’hot’]"> 

<!-- only grabs title elements that have a priority  value of hot -->

The @ symbol in front of priority designates that we are searching on an attribute value. What if you want to retrieve all title nodes that have any priority value set:

<xsl:template match="title[@priority]"> 

You can even mix and match. Here’s how you pick out all the date children nodes of title nodes with a hot priority attribute:

<xsl:template match="//title[@priority=’hot’]/date"> 

Notice that you can also use similar notation to find those elements that have a certain value. For example, let’s say that in a slightly different schema, we are storing priority values in XML elements, not attributes. If we want to retrieve all the title elements that have a priority element set to hot, here’s how we’d do it:

<xsl:template match="//title[priority=’hot’] "> 

All we have to do is drop off the @ symbol and we can work with the value as stored in an XML element.

Here’s how you retrieve the first and last nodes in a group:

<xsl:template match="memo/title[first()]"> 

<xsl:template match="memo/title[last()]"> 

You could also select the first node with:

<xsl:template match="memo/title[1]"> 

Or even:

<xsl:template match="memo/title[position() = 1]"> 

In other cases, you might need to select multiple branches in the same document. For example, here’s how you might pick out memo titles and authors at the same time:

<xsl:template match="memo/title | memo/author"> 

You could, of course, select all nodes in a certain context with *:

<xsl:template match="memo/*"> 

As you can see, the XPath query language is powerful and flexible—it allows you to retrieve just about any combination of nodes you need, and that can make all the difference when you’re working with XSLT and other XML technologies.

Tags: No Comments