.NET and XML: XPath Queries
The W3C (the World Wide Web Consortium, http://www.w3.org) published the XML 1.0 specification on February 10th, 1998. The XML 1.1 specification was published six years later, on February 4th, 2004. In these six years, XML has taken the industry by storm. XML has become the standard for how to describe and exchange data.
The current primary development platforms, .NET and J2EE, support XML natively. All modern enterprise applications—may it be a SQL Server or Oracle database, a BizTalk Server, an Office suite or any of the other thousands of applications—support XML to various degrees. You will be pretty hard pressed to find an application that does not support or use XML.
There is more to XML then just a way of describing data. Over the years, a number of XML-based standards have emerged. Among the most fundamental ones are XSD (XML Schema Definition), XPath Query, XSLT (Extensible Stylesheet Language Transformation), SOAP (Simple Object Access Protocol), and WSDL (Web Services Description Language). All build on top of the XML syntax.
This article begins a series. The first three articles explain the fundamentals of XPath queries, XSD schemas, and XSLT. The following articles look at how well these standards are supported by the .NET framework and what are the most important namespaces and types. This series of articles is not intended as a comprehensive description of all the .NET types around XML. The goal, rather, is to provide a good introduction so you understand the XML capabilities of the .NET framework and can start leveraging them for your current .NET projects.
The Sample XML Document for the Series of Articles
This series of articles assumes that you are familiar with XML itself. The sample XML document used throughout the articles is a list of employees, which must have for each employee the first name, last name, phone number, and e-mail address, and also can provide the job title and a Web address.
<?xml version="1.0" encoding="utf-8"?> <Employees> <Employee ID="1"> <FirstName>Klaus</FirstName> <LastName>Salchner</LastName> <PhoneNumber>410-727-5112</PhoneNumber> <EmailAddress>firstname.lastname@example.org</EmailAddress> <WebAddress>http://www.enterprise-minds.com</WebAddress> <JobTitle>Sr. Enterprise Architect</JobTitle> </Employee> <Employee ID="2"> <FirstName>Peter</FirstName> <LastName>Pan</LastName> <PhoneNumber>604-111-1111</PhoneNumber> <EmailAddress>email@example.com</EmailAddress> <JobTitle>Sr. Developer</JobTitle> </Employee> </Employees>
A quick note to editing XML documents in Visual Studio .NET 2003: When you open up a XML document, you see at the bottom of the window an "XML" and "Data" tab. The XML tab allows you to edit the XML. It also formats the XML nicely for you with indentions and all that. The Data tab parses the XML and shows a data grid. You can add new nodes by adding new rows to the data grid and entering corresponding values. Using the example data, this would be new Employees.
You also can show a document outline through the "View | Other Windows | Document Outline" menu, which shows you a hierarchy of all the nodes in the XML document. Selecting a node in the "document outline" will automatically select it in the XML document too.
The Fundamentals of XPath Queries
Once you have data in XML format, you will want to be able to navigate and search its nodes. You don't want to have to parse the whole XML document to find that there are two Employee nodes. That would be terribly inefficient. You want to apply an XPath query, which then gives you all the matching nodes. To find all Employee nodes, you would run the following XPath query:
If you use the table above, this query will return two nodes, each representing an employee. This makes it very easy to find matching nodes and walk through the result set.
XPath is a standard (XPath 1.0) and can be found at http://www.w3.org/TR/xpath/. The working draft of XPath 2.0 can be found at http://www.w3.org/TR/2001/WD-xpath20-20011220/. Let's look more closely at some of the most common XPath operators.
|/ (child operator)||Refers to the root of the XML document when used at the beginning of the XPath expression. The child operator is used to specify the next child to select. The expression "/Employees/Employee", for, example says, start at the root of the XML document, select the Employees node and then select all the Employee child nodes within the Employees node. This will return the two Employee nodes in the sample XML document.|
|// (recursive descendant operator)||The recursive descendant operator indicates to include all descendant nodes in the search. Using the operator at the beginning of the XPath expression means you start from the root of the XML document. The expression "//LastName" starts at the root and finds any LastName node. The expression "/Employees//LastName" selects the Employees node and then, within that node, finds any LastName node. It yields the same result, but searches in a different way.|
|* (wildcard operator)||The wildcard operator finds any node. The expression "/*" finds any node under the root, which in our case is Employees. The expression "/Employees/*" means find any node under the Employees node, which in our case results with the two Employee nodes. Now what is the difference between the "/Employees" and "/Employees/*" expression? The first expression returns the Employees node but the second node finds any node under the Employees node, meaning it returns the two Employee nodes. The expression "//*" means to select any node including descendant nodes, so it will effectively list every single node in the complete XML document.|
|. (current context operator)||The current context operator refers to the current context. For example, you have written some code that selected the Employees node and then from there you run the expression "./Employee", which means it starts out from the currently selected Employees node and then selects the two Employee nodes. The expression "Employee" would yield the same result because it also starts out from the current context. Similar the expression ".//LastName" means start from the current context, the Employees node, and find any LastName node including any descendant nodes.|
|.. (parent operator)||The parent operator refers to the parent. For example, the expression "/Employees/Employee/.." returns the Employees node because you navigate down to the Employee nodes and then tell it to return its parent, which is the Employees node.|
|@ (attribute operator)||The attribute operator refers to an attribute instead of an element. The expression "/Employees//@ID" selects any ID attribute it finds under the Employees node. Now, keep in mind that the XPath query always returns the selected node. In the case of an attribute, the node below it is its value. So, the expression really two returns nodes, each with the value of each selected attribute. Furthermore, you can use the wildcard operator with attributes, so "/Employees//@*" means any attribute underneath the Employees node.|
|[ ] (filter operator)||You can apply a filter operator to filter the selected nodes. This works with attributes and with elements. The expression "/Employees/Employee[@ID=1]" returns any Employee node under the Employees node that has an ID attribute with the value one. You also can apply filters that just say that an attribute or element with that name needs to be present. For example, the expression "/Employees/Employee[WebAddress]" returns Employee nodes that have a WebAddress node as child. The expression "/Employees/Employee[FirstName='Klaus']" returns the Employee node that has a FirstName node with the value Klaus.|
|text() function||The "text()" function refers to the text of the selected node or attribute. The expression "//Employee//text()" does not list all the descendant nodes of all Employee nodes but rather the value for each descendant node. The expression "//Employee/FirstName[text()='Klaus']" lists all FirstName nodes which have a value of Klaus.|
|[ ] (collection operator)||When your expression returns more then one node with the same name, you have a collection returned. The expression "//Employee" returns two Employee nodes, which is nothing more than a collection of Employee nodes. You can apply a collection operator and specify which item from the collection you want to select. Keep in mind that the index starts at one. The expression "//Employee" returns the second Employee node. The order of the selected nodes is the same order as in the XML document. You can use the collection operator in any blend, such as "//Employee/LastName", which selects the first Employee node and then from there the LastName node.|
|( ) (group operator)||The collection operator can sometimes have some odd side effects. Assume you have two Employee nodes and each has two Job nodes. What does the expression "//Employee/Job" return? It returns the first Job node for each selected Employee node. But, using the group operator allows you to apply explicit precedence to selections. The expression "(//Employee/Job)" first selects all Job nodes for all Employee nodes and from that collection it returns the fourth node. The group operator can only be applied to the top level expression; for example, "//Employees/(Employee/FirstName)" is invalid.|
|comment() function||Returns a comment node. The expression "//comment()" returns any comment node in the XML. The expression "/Employees/comment()" returns the comment nodes under the Employees node.|
|node() function||XML documents consist of elements, attributes, and their values, each being a node. So, in XPath expressions you can use a node() function instead of a node name or the text() function. It is a generic way to address a node. The expressions "//Employee/JobTitle/node()" and "//Employee/JobTitle/text()" return the same result, the value of both JobTitle nodes. But, "//Employee//node()" will not just return the elements but also the values of each element, because both are nodes.|
|| (union or set operator)||Returns the union of one or more location paths. The expression "//LastName | //FirstName" returns all the LastName and FirstName nodes. It preserves the order of the elements as in the XML and does not return any duplicates. The two location paths "//Employee[@ID=1] | //Employee[FirstName='Klaus']" return the same nodes but the union of these two returns just the one unique node.|
The table does not represent a complete list, but it lists the most basic operators and functions. As you can see from the samples, this already enables you to build fairly complex XPath queries. Keep in mind that the precedence of the operators is the group operator, followed by the filter operator, the child operator, and recursive descendant operator followed by the rest.