Altova® XMLSpy® contains the powerful XPath Analyzer window and XPath builder, which assist you in building and verifying XPath 1.0 and XPath 2.0 expressions. In the XPath Analyzer window, you simply enter an XPath expression, and XMLSpy displays the results in real time. As you're composing an expression, correct syntax is shown in black, with incorrect entries highlighted in red. Clicking any node in the result window highlights the corresponding node in the file itself. The XPath builder allows you to highlight any node in your document and automatically copy the correct XPath to the clipboard. Both tools allow you to check your XPath expressions quickly and make changes in an intuitive way, saving hours of debugging time.

Editing complex XPath expressions in the XPath toolbar can be sometimes difficult due to the size limitation. This view allows editing of multi-line expressions. The executed expressions are stored in a history list and they can be reused as necessary. The results of an XPath query are shown as a list in the results panel. You can save the results to a file by clicking the Save Results option from the right-click menu or even print the XPath results. Clicking on a result line will highlight the corresponding part from the document.

Introductory tutorial and a growing list of resources. Subscribe to the RSS feed to stay up to date.

Download chapter 1 of the "XPath 2.0 Programmers Reference", which covers the following topics: Top-level XPath constructs and the lexical rules for using whitespace and comments, Basic XPath operators for writing arithmetic and Boolean expressions, Three operators for combining the results of path expressions: union, intersect, and except, How XPath 2.0 supports sequences, Where to access a complete listing of all functions in the core function library, How to define the syntax of XPath regular expressions as used in the new functions matches(), replace(), and tokenize(), and much more. Free printable PDF download.

I have been snuffling around various Java APIs relating to XPath this week in order to implement draft ISO Schematron in Java. But the current batch of Java APIs seem to be missing the functions I need: this must be holding back other developers too.

Some very interesting work has been going on with the classes in the System.Xml namespace. Daniel Cazzulino blogs about an XseReader implementation he has been working on for providing XML Streaming Events. I had been using a similar implementation for trying to write a .NET version of an RssValidatingReader awhile back, but gave up due to the complexity of managing an ambiguous stack for co-occurrence validation.

The XPathNodeIterator provides methods to iterate over a set of nodes created as the result of an XPath query, or a result tree fragment converted to a node set by use of the node-set method. The XPathNodeIterator enables you to iterate over the nodes within that node set. Once a node set is retrieved, the XPathNodeIterator class provides a read-only, forward-only cursor to the selected set of nodes.

The XPathNavigator class provides read-only random access to data, and is designed for use as an input to XSLT. It is implemented on the XPathDocument, XmlDataDocument, and XmlDocument. The XPathNavigator is based upon the W3C Data Model as described in section 5 of the XML Path Language (XPath) recommendation.

As I programmed an XPath-only implementation of the Schematron specification (soon an ISO standard and very cool XML validation language, incredibly flexible and powerfull), called (surprisingly) Schematron.NET, and part of the NMatrix project, I found many interesting things about the internals of XPath execution. And I needed to dig deep inside it because my implementation had to be more performant than the reference implementation based on XSLT. And it ended being an average 50% faster than the fastest-XSLT-engine-executed version. During that trip, I found the following useful tips:

"Everybody" knows that precompiling your XPath expressions ahead of time, usually in static .ctors, improves execution performance. But what's actually happening at that "compilation" time? Unlike what many believe, compiled IL is NOT being generated, neither on-the-fly assemblies or anything like it. It's NOT like RegEx compilation, sadly. But what's going on is important for performance because it involves parsing, AST (abstract syntax tree) building, etc.

The XML team has recently started getting questions about our position on XQuery 1.0, XPath 2.0 and XSLT 2.0. Yesterday my boss, Mark Fussell, posted about why we have decided to implement XQuery 1.0 but not XSLT 2.0 in the next version of the .NET Framework. Some people misinterpreted his post to mean that the we chose to implement XQuery 1.0 over XSLT 2.0 because we prefer the syntax of the former over that of the latter. However decisions of such scale aren't made that lightly.

I've just released the initial version of XPath Methods, arbitrarily set at 0.7. XPath Methods is a Zope product that glues FourThought's 4XPath to ParsedXML, so that you can send XPath queries to ParsedXML XML documents.

Class::XPath is a Perl module which adds XPath-style matching to your object trees. This means that you can find nodes using an XPath-esque query with match() from anywhere in the tree.

An application to visualize XPath Queries

There are currently two XPath products to use with Zope. Each of these solutions is based on the 4Suite XPath processor and require installation of the 4Suite tools.

A posting from Bob McWhirter announces the availability of Jaxen Version 1.0-beta-4. With development hosted on SourceForge, the Jaxen project is developing a Java XPath Engine.

The SAXPath project is a Simple API for XPath. SAXPath is analogous to SAX in that the API abstracts away the details of parsing and provides a simple event based callback interface.

If you're a power user or developer familiar with Microsoft Access (or other products that use the Microsoft Jet database engine), you probably think of the SQL language when thinking about queries.

The XML Query Working Group and the XSL Working Group have released nine Working Drafts. Six are in Last Call through 15 February 2004. Comments on all of these documents are invited. Visit the XML home page.

XPath is a language for addressing parts of an XML document, used most commonly by XSLT. There are various APIs for processing XPath. For the purposes of this article I will use the open source Jaxen API. Jaxen is a Java XPath engine that supports many XML parsing APIs, such as SAX, DOM4J, and DOM. It also supports namespaces, variables, and functions.