July 14, 2011, 2:23 a.m.
posted by pitbull
A Very Brief Overview of the XQuery LanguageBefore diving into an examination of the classes in the .NET Framework, it's necessary that you have an understanding of the XQuery language so you can construct queries against data sources. Covering the full syntax of the XQuery language is well beyond the scope of this book, but we will discuss the minimal essentials here for the queries used in this chapter. Look for the book XQuery by Michael Brundage (Boston, MA: Addison-Wesley, ISBN 0-321-16581-0), due to be published in 2004, for a complete description of the XQuery language. However, to start you down the road, XQuery is based on XPath 1.0. So if you know XPath, you are well on the way to understanding XQuery. Below we will outline the essential additions beyond XPath for the queries used in this book. Where's the Data Located?In all queries, the XML document itself has to be referenced in some way. This is referred to as the document context. There are three ways to achieve this in the XQuery specification, plus a fourth provided by the use of XML Views in the .NET Framework. These are listed below.
FLWOR ExpressionsThe acronym FLWOR, pronounced "flower," is created from the keywords used in an XQuery expression—for, let, where, order by, and return—which support iteration and binding of variables to results. FLWORs are probably the most common expression construct and can be considered to be the SQL Select * from table where... equivalent in XQuery. The for keyword provides iteration, and the let keyword provides variable binding. Here is an example:
<Customers>
{
for $i in document('customers.xml')/Customers/Customer
where $i[@City='London']
<CustomerName>{return $i/@name}</CustomerName>
}
</Customers>
The first thing to notice is $i, which declares a variable called i. The document function and the path expression /Customers/Customer retrieve all the Customer elements from the customers.xml document, and the for expression starts an iterative loop over the values, which are individually bound to the $i variable. The where clause applies a filter, or predicate, to match only Customer elements whose City attribute has the text value of London. Finally, we construct a <CustomerName> element and insert into it the value of the name attribute from the current Customer element using the return statement. The ability to construct XML on the output is also shown by the creation of an enclosing <Customers> element in the output. The end result may look something like this: <Customers> <CustomerName>Alex Homer</CustomerName> <CustomerName>Mark Fussell</CustomerName> <CustomerName>David Sussman</CustomerName> </Customers> Another point to note in the query above is the use of curly braces ({}), which indicate this is a query statement that needs to be executed, not a literal piece of XML that is written to the output (e.g., within the constructed <CustomerName> element). Without the curly braces, the XQuery processor would treat this as element content rather than an XQuery expression that needs to be executed, that is: <CustomerName>return $i/@name</CustomerName> If some of this syntax seems strange at first, it is worth spending some time working with the different examples to achieve familiarity. Then you will start to gain an understanding of how powerful this query language is and the extensive capabilities you can take advantage of when querying and manipulating XML. Reading the W3C XML Query Use Cases specification also helps clarify the syntax with examples. To learn more about the XQuery syntax, functions, and operators, check out the following W3C specifications:
|
- Comment