by Thomas Erl
By abstracting certain “utility” functions, a relatively modular set of XML specifications has emerged. Functional redundancy is avoided by allowing these supplementary features to be reused by other standards.
XPath is an example of such a utility specification. It can be used independently within custom programming logic to interact directly with the XML Document Object Model, or it can be intrinsically incorporated within other specifications. Essentially, XPath provides an expression syntax used to create location paths.
Elements or element values within XML documents can be searched and filtered using a variety of XPath functions. Statements that identify location paths are called expressions. XPath expressions are mobile, in that they can be embedded within other types of XML documents.
XPath is one of the few remaining XML specifications that does not consist of an XML-compliant syntax itself. Its nature is purely functional, and its expression syntax has become highly integrated with XQuery and XSLT specifications. As previously mentioned, version 2.0 of the XPath specification shares the same data model as Query 1.0 and XSLT 2.0.
XPath approaches the addressing of an XML document tree similarly to how traditional file paths refer to directory structures, or how virtual paths refer to internal Web site structures. As a result, XPath addresses can also be relative or absolute.
Note: When discussing elements within the context of a document tree, the term node is frequently used instead. Although it is important to have a basic understanding of how XPath works, in particular when supporting XSLT, it is not a technology that commonly acts as a key part of an integration architecture. XPath statements are typically found within XSLT templates and various programming routines that interact with the XML parser API.
The example below starts a path with the forward slash symbol indicating that the statement applies to the root node:
The first statement selects the root node book; the second selects all author elements that have the book element as a parent.
Starting the path statement with a double forward slash indicates that elements anywhere in the document that match the path are selected, as follows:
These are very basic applications of XPath. Much more complex path definitions can be created, as below:
The first statement selects all author elements that have a location attribute with the value "Vancouver". The second selects all elements that have exactly three category child elements.
- Inside XML Schemas
- SOAP in a Nutshell
- Transforming Data with XSLT
- Understanding DTDs
- Why SAX is Good for DOM
- What You Should Know about XPath
- An XHTML Primer
- XLink - Inside and Out
- Data Access with XQuery
- XSL versus CSS
- Another Introduction to XML
- Unifying Corporate Data & Documents
- Replacing HTML Documents with XML
- Meta-Enable Your Enterprise
- The XML Data Custodian
- Integrating XML into the Enterprise
- The Wireless Enterprise
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable
For more information about these books, visit: www.servicetechbooks.com