Posts in this series:
Punctuation in XPath, part 1: dot (“.”)
Punctuation in XPath, part 2: slash (“/”)
Punctuation in XPath, part 3: “@” and “..”
Punctuation in XPath, part 4: predicates (“[…]”)
Punctuation in XPath, part 5: “//”
In this series, we’ve first taken a look at seen what “.” means, and then what “/” means. We’ve also seen that we can use any expression as a step in a path expression, parenthesizing it as necessary. In this third installment on XPath punctuation, we’ll learn about the most common type of step in a path expression, the “axis step” and how it can be abbreviated.
All path expression steps can be categorized into two kinds:
A filter expression is a primary expression (e.g., variable reference, literal, context item expression, function call, or parenthesized expression) followed by zero or more predicates. An axis step is a step that selects nodes along a specific axis that is followed by zero or more predicates. Let’s get more familiar with these expression steps by walking through examples.
Here’s an example document we’re going to work from, using XQuery to bind it to a variable:
declare variable $doc := document { <doc> <items> <meta id="firstGroup"/> <item>1</item> <item>2</item> </items> <items> <meta id="secondGroup"/> <item>3</item> <item>4</item> </items> </doc> }; declare variable $items := $doc/doc/items/item;
Consider the following four-step expression. This selects the id
attribute of each <meta>
child of the parent of the first node in $items
:
$items[1]/../meta/@id
The first step $items[1]
is a filter expression. The remaining three steps are all axis steps. In fact, all three make use of some XPath syntax sugar. The following expanded expression is what the above expression is short for:
$items[1]/parent::node()/child::meta/attribute::id
We see three different axes in use here: “parent”, “child”, and “attribute”. It’s never necessary to use attribute::
or child::
explicitly, since “@” is always short for attribute::
and since child::
is the default when you omit the axis specifier (except when using the lesser-used attribute()
or schema-attribute()
node tests, in which case attribute::
is the default—either way, you can always use the short form). Most often, you won’t explicitly use parent::
either, however it’s sometimes useful to test the parent’s name or node type, using an expression like parent::foo
or parent::document-node()
.
There are in fact 13 XPath axes altogether, and you can use any of them in their expanded form:
self::
child::
attribute::
namespace::
(“deprecated” in XPath 2.0 and disallowed in XQuery)descendant::
descendant-or-self::
following::
following-sibling::
parent::
ancestor::
ancestor-or-self::
preceding::
preceding-sibling::
I won’t go into what sets of nodes each axis selects (you might try experimenting with this handy online XPath axes visualizer to learn some by example), but suffice it to say that the evaluation of an axis step conceptually occurs in three stages, corresponding to the three parts of an axis step:
The three parts in the axis step of the following expression are “descendant::”, “item”, and “[4]”:
$doc/descendant::item[4]
$doc
provides the context node, and from there, the axis step is evaluated (at least conceptually) as follows:
Using XQuery, you could simulate this conceptual process by explicitly breaking the evaluation down into three stages of filtering. The following expression is a longwinded way of selecting the same nodes, just to make my point:
let $matches-axis := $doc/descendant::node(), (: everything on axis :) $matches-node-test := $matches-axis/self::item, (: filtered :) $matches-predicate := $matches-node-test[4] (: filtered again :) return $matches-predicate
Now that you have a general idea of what an axis step is, here are all the axis-related syntax shortcuts in XPath:
Syntax | What it’s short for | Notes or exceptions |
---|---|---|
@ |
attribute:: |
|
.. |
parent::node() |
|
foo |
child::foo |
where “foo” is any node test except attribute(…) or schema-attribute(…) |
attribute(foo) |
attribute::attribute(foo) |
where “attribute(foo)” is any attribute(…) or schema-attribute(…) node test |
// |
/descendant-or-self::node()/ |
Continue Reading:
Like what you just read, here are a few more articles for you to check out or you can visit our blog overview page to see more.
In this post, we dive into building a full five-card draw poker game with a configurable number of players. Written in XQuery 1.0, along with MarkLogic extensions to the language, this game provides examples of some great programming capabilities, including usage of maps, recursions, random numbers, and side effects. Hopefully, we will show those new to XQuery a look at the language that they may not get to see in other tutorials or examples.
If you are getting involved in a project using ml-gradle, this tip should come in handy if you are not allowed to put passwords (especially the admin password!) in plain text. Without this restriction, you may have multiple passwords in your gradle.properties file if there are multiple MarkLogic users that you need to configure. Instead of storing these passwords in gradle.properties, you can retrieve them from a location where they’re encrypted using a Gradle credentials plugin.
Apache NiFi introduces a code-free approach of migrating content directly from a relational database system into MarkLogic. Here we walk you through getting started with migrating data from a relational database into MarkLogic
Don’t waste time stitching together components. MarkLogic combines the power of a multi-model database, search, and semantic AI technology in a single platform with mastering, metadata management, government-grade security and more.
Request a Demo