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 > ----------------------------------------- > >Received on Tuesday, 15 July 2003 10:57:28 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:42 UTC