The new website for MarkLogic is Visit it.

Punctuation in XPath, part 3: “@” and “..”

Back to blog
3 minute read
Back to blog
3 minute read

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:

  1. Filter Expression
  2. Axis Steps

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 {
      <meta id="firstGroup"/>
      <meta id="secondGroup"/>
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:


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:


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().

Axis Step Evaluation

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:

  1. Axis specifier (one of the above 13 axes or an abbreviation)
  2. Node test (either a name or kind test, such as foo, *, or node())
  3. Predicate (zero or more of them)

The three parts in the axis step of the following expression are “descendant::”, “item”, and “[4]”:


$doc provides the context node, and from there, the axis step is evaluated (at least conceptually) as follows:

  1. Get all nodes along the axis (descendant)
  2. Of those, filter out the ones not matching the node test (item)
  3. Of those, filter out the ones not matching the predicate ([4])

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

Syntax Shortcuts

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:

Part 4: predicates (“[…]”)

Part 5: (“//”)

Share this article

Read More

Related Posts

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.


Poker Fun with XQuery

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.

All Blog Articles

Protecting passwords in ml-gradle projects

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 file if there are multiple MarkLogic users that you need to configure. Instead of storing these passwords in, you can retrieve them from a location where they’re encrypted using a Gradle credentials plugin.

All Blog Articles

Getting Started with Apache Nifi: Migrating from Relational to MarkLogic

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

All Blog Articles

Sign up for a Demo

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