Re: XQuery Normalization

On Tue, 2003-07-15 at 10:36, Philippe Michiels wrote:
> Hi,
> 
> There seems to be some curiosity in the normalization of the double slash 
> operator in XPath expressions (XQuery 1.0 and XPath 2.0 formal semantics 
> draft), which is normalized as follows:
> 
> ["//" RelativePathExpr]Expr    ==    
> [fn:root( self::node() ) "/" descendant-or-self::node() "/" 
> RelativePathExpr]Expr
> 
> Without any predicates, these expressions, indeed return the expected result. 
> However, when an index is applied after the // operator, for instance:
>     //a[2],
> 

The reason for the 'curiosity' is to be able to treat both //a and //@a
through the same normalization rule in a unified way.

> a problem arises. Now, this path expression is (in a first step) normalized 
> into
>   /descendant-or-self::node()/child::a[2]
> (selects all second a-children of the descendant nodes),
> 
> which is something totally different than
>  /descendant::a[2]
> (selects the second a-descendant)
> 
> which is the behavior I would expect. Off course, someone who knows the 
> normalization rules understands why the two expressions yield different 
> results, but is this really what the designers of XPath had in mind?
> 

That is a consequence which is documented in the XPath spec. See
[Section 3.2.4 Abbreviated syntax] of the XPath 2.0 working draft, point
3., which says:

<<
Note that the path expression //para[1] does not mean the same as the
path expression /descendant::para[1]. The latter selects the first
descendant para element; the former selects all descendant para elements
that are the first para children of their parents.
>>

Best,
- Jerome


> -- Philippe
> -----------------------------------------
> Philippe Michiels
> ADReM Research Group --  dept. WisInf   
> Universiteit Antwerpen
> Middelheimlaan 1
> 2020 Antwerpen
> 
> tel: 32 (3) 218 0880
> http://win-www.ruca.ua.ac.be/u/michiels
> -----------------------------------------
-- 
Jerome Simeon <simeon@research.bell-labs.com>

Received on Tuesday, 15 July 2003 10:56:15 UTC