- From: Bas de Bakker <bas@x-hive.com>
- Date: Tue, 15 Jul 2003 16:57:26 +0200
- To: "Philippe Michiels" <philippe.michiels@ua.ac.be>, <www-ql@w3.org>
- Cc: <jan.hidders@ua.ac.be>
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