Path Expressions

Path Expressions

We saw earlier in the chapter many examples of path expressions. Here are some more:

 $auction/articles  has type  element(articles) $auction/articles/article  has type  element(article)+ $auction/itesm/article  is a static type error  

These assume that $auction has type element(auction) as defined in Listing 4.2. The first expression has type element(articles) because there is exactly one articles element in an auction element. The second expression has type element(article)+ because there are one or more article elements in an articles element. The third expression is a static type error, because there is no itesm element in an auction element. Here is how the error is caught: the type rules assign to the last path expression the type empty() , which is the type of the empty sequence. Assigning this type to any expression other than () raises a static type error, since it is unlikely someone would intentionally write an expression other than () that always returns the empty sequence.

Another operator on path expressions is union.

 $auction/(articles  users)  has type  ( element(articles)  element(users) )+ 

This path expression selects all articles and users elements that are children of the auction element. The static typing inference rules compute the type in two parts : a choice of items and an occurrence indicator. The auction element has one articles element as a child, and one users element as a child, so the result is a choice of articles or users elements. The occurrence indicator is one-or-more, which is computed by approximate arithmetic: A union of one item and one item contains one-or-more items.

One might wonder why this expression is not given a more precise type, such as the following:

 $auction/(articles  users)  doesn't have type  (element(users) , element(articles)) 

From the auction schema, we know that an auction element contains exactly one users element followed by one articles element. So why not give this more precise type? There is a trade-off here: Increased precision of typing requires increased complexity in the typing rules. As an engineering judgment, the designers of XQuery chose simple rules that apply uniformly to all path expressions, and yield types good enough for most practical purposes.

A type consisting of a choice of items and an occurrence indicator is called a factored type . There is always a unique, best way to factor a type: Take the union of all items that occur in the type and compute the occurrence indicator by approximate arithmetic (e.g., one plus one is one-or-more).

If the type of a sequence is in factored form, then any reordering of the sequence also has the same factored type. The result of a path expression is always sorted in document order; therefore, the type of a path expression is always in factored form, and any reordering of the sequence to preserve document order does not change its type. For instance, users precedes articles in the declaration of the auction element, but this doesn't affect the type above.

Path expressions may contain wild cards. Here are some examples:

 $auction/*  has type  ( element(users)  element(articles)  element(bids) )+ $auction/*/*  has type  ( element(user)  element(article)  element(bid) )+ 

An auction element has three children, the users and articles and bids elements. So the first expression's type is a choice of these three element types, and its occurrence indicator is one-or-more (since one plus one plus one is one-or-more). A users element has as children one or more user elements, and similarly for the other two. So the second expression's type is a choice of the three element types, and its occurrence indicator is one-or-more (since one-or-more plus one-or-more plus one-or-more is one-or-more).

Another operator on path expressions is the descendant operator. Here is an example:

 $article//@idref  has type  (attribute(@idref,xs:string)  attribute(@idref,xs:anySimpleType))+ 

This example appeared in line [28] of Listing 4.4 and generated the type error reported earlier in the section entitled "Debugging." There is one idref attribute of type string in a seller element, and there may be zero or more idref attributes of any simple type in an description element. So the expression's type is a choice of the two attribute types, and its occurrence indicator is one-or-more (since one plus zero-or-more is one-or-more).

The type of a path expression may include a locally declared element. Here's a path expression that selects all name elements occurring in user or article elements:

 $auction//(userarticle)/name  has type  ( element(type(User)/name)  element(type(Article)/name) )+ 

A user element contains one name element locally declared in type User , and an article element contains one name element locally declared in type Article ; therefore, the expression's type contains both locally declared elements.

The expression $auction//name selects all name elements within $auction . Referring back to the schema in Listing 4.2, we see that it explicitly declares name elements in the two places already considered (context User and context Article ), but it also allows for name elements within the description element, which is permitted to contain any content whatsoever. So the type of the expression is

 ( element(type(User)/name)  element(type(Bid)/name)  element(name,xs:anyType) )+ 


XQuery from the Experts(c) A Guide to the W3C XML Query Language
Beginning ASP.NET Databases Using VB.NET
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 102

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net