RE: XQuery Normalization

This was already true in XPath 1.0.  See the note in section 2.5 of the
specification.  Because of backward compatibility, nobody is going to
change it.

Regards,
Bas de Bakker
X-Hive Corporation

> -----Original Message-----
> From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of
> Philippe Michiels
> Sent: Tuesday, July 15, 2003 16:36
> To: www-ql@w3.org
> Cc: jan.hidders@ua.ac.be
> Subject: XQuery Normalization
> 
> 
> 
> 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],
> 
> 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?
> 
> -- 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
> -----------------------------------------
> 
>