 by Thomas Erl |
XML Core Technology | |||
 |
||||
|
||||
| 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: |
| /book /book/author |
| 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: |
| //title |
SOA: Principles of Service Design by Thomas Erl  An in-depth guide dedicated to service engineering with a thorough exploration of the design principles that comprise the service-orientation design paradigm (including a comparison with object-orientation). 
Service-Oriented Architecture:Concepts, Technology, and Design by Thomas Erl The first "how-to" guide to building SOA, providing coverage of WS-* specifications, .NET and J2EE platforms, and step-by-step processes for service-oriented analysis and design. 
Service-Oriented Architecture:A Field Guide to Integrating XML and Web Services by Thomas Erl The best-selling guide to service-oriented integration, providing hundreds of integration strategies and over sixty best practices. For more information about either book, visit: www.soabooks.com |
About SOA Systems
SOA Systems Inc. provides strategic SOA consulting services and offers a comprehensive SOA training program. For more information see: • www.soasystems.com • www.soatraining.com |
| These are very basic applications of XPath. Much more complex path definitions can be created, as below: |
| //author[normalize-space(@location)='Vancouver'] //*[count(category)=3] |
|
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.
|
|
|
|
|
|
|
| Home | Copyright © 1999-2007 SOA Systems Inc. |