Home arrow XML arrow Page 2 - Using Predicates with XQuery

Using Predicates with XQuery

In this second part of a three-part series on extracting information from XML documents, you'll learn how to use predicates in path expressions. This article is excerpted from chapter four of the book XQuery, written by Priscilla Walmsley (O'Reilly, 2007; ISBN: 0596006349). Copyright 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

Author Info:
By: O'Reilly Media
Rating: 5 stars5 stars5 stars5 stars5 stars / 6
February 28, 2008
  1. · Using Predicates with XQuery
  2. · Comparisons in Predicates
  3. · Using Positions in Predicates
  4. · The position and last functions

print this article

Using Predicates with XQuery - Comparisons in Predicates
(Page 2 of 4 )

The examples in the previous section use general comparison operators like = and <. You can also use the corresponding value comparison operators, such as eq and lt, but you should be aware of the difference. Value comparison operators only allow a single value, while general comparison operators allow sequences of zero, one, or more values. Therefore, the path expression:

  doc("prices.xml")//priceList[@effDate eq '2006-11-15']

is acceptable, because each priceList element can have only one effDate attribute. However, if you wanted to find all the priceList elements that contain the product 557, you might try the expression:

  doc("prices.xml")//priceList[prod/@num eq 557]

This will raise an error because the expression prod/@num returns more than one value per priceList. By contrast:

  doc("prices.xml")//priceList[prod/@num = 557]

returns a priceList if it has at least one prod child whose num attribute is equal to 557. It might have other prod children whose numbers are not equal to 557.

In both cases, if a particular priceList does not have any prod children with num attributes, it does not return that priceList, but it does not raise an error.

Another difference is that value comparison operators treat all untyped data like strings. If we fixed the previous problem with eq by returning prod nodes instead, as in:

  doc("prices.xml")//priceList/prod[@num eq 557]

it would still raise an error if no schema were present, because it treats the num attribute like a string, which can't be compared to a number. The = operator, on the other hand, will cast the value of the num attribute to xs:integer and then compare it to 557, as you would expect.

For these reasons, general comparison operators are easier to use than value comparison operators in predicates when children are untyped or repeating. The down side of general comparison operators is that they also make it less likely that the processor will catch any mistakes you make. In addition, they may be more expensive to evaluate because it's harder for the processor to make use of indexes.

blog comments powered by Disqus

- Open XML Finally Supported by MS Office
- XML Features Added to Two Systems
- Using Regions with XSL Formatting Objects
- Using XSL Formatting Objects
- More Schematron Features
- Schematron Patterns and Validation
- Using Schematron
- Datatypes and More in RELAX NG
- Providing Options in RELAX NG
- An Introduction to RELAX NG
- Path, Predicates, and XQuery
- Using Predicates with XQuery
- Navigating Input Documents Using Paths
- XML Basics
- Introduction to XPath

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials