- From: Michael Kay <mhk@mhk.me.uk>
- Date: Wed, 16 Feb 2005 17:17:39 -0000
- To: "'Mukul Gandhi'" <mukul_gandhi@yahoo.com>, <public-qt-comments@w3.org>
I feel the need for these myself sometimes, but in XPath 2.0 expressions are much more composable, so wherever you can write following-sibling::x you can also write (following-sibling::x|self::x) It would be even more composable, of course, if we allowed (following-sibling|self)::x which would also allow useful things like (preceding|ancestor)::x However, these are all things that can be accomplished without inordinate difficulty in XPath 2.0 as currently defined, and we're past the stage now of adding new features just because they seem cool. Of course, it's a little untidy to have the -or-self option on some axes and not others. But untidiness isn't a good enough reason to withdraw or deprecate a facility that many people are happily using, nor is it a good enough reason to add features that the world can live without. So (and this is a personal response) I think the answer is almost certainly: nice idea, but no. Michael Kay http://www.saxonica.com/ > -----Original Message----- > From: public-qt-comments-request@w3.org > [mailto:public-qt-comments-request@w3.org] On Behalf Of Mukul Gandhi > Sent: 16 February 2005 16:52 > To: public-qt-comments@w3.org > Subject: [XPath]Need of another Axes! > > > Hello, > I have a suggestion for XPath 2.0 language! I am > refering to the latest Working Draft of XPath 2.0(Feb > 11 2005') at URL http://www.w3.org/TR/xpath20/ > > Presently XPath 2.0 defines the following Axes - > 1) ForwardAxis > ----------- > child > descendant > attribute > self > descendant-or-self > following-sibling > following > namespace > 2) ReverseAxis > ----------- > parent > ancestor > preceding-sibling > preceding > ancestor-or-self > > I feel the need for 2 more Axes definitions; namely - > following-sibling-or-self , and > preceding-sibling-or-self > > Just like we have descendant-or-self and > ancestor-or-self , why should not we also have > following-sibling-or-self and > preceding-sibling-or-self .. > > Sometimes, we need this functionality, and we have to > do workaround like - > > self | following-sibling , and > self | preceding-sibling > > i.e. we have to use the union (|) operator.. > > I feel, providing following-sibling-or-self and > preceding-sibling-or-self will make Axes definitions > more complete.. > > If these new Axes cannot be incorporated, probably > descendant-or-self and ancestor-or-self Axes should be > deprecated (just like the namespace axis is deprecated > in XPath 2.0).. > > I also feel, if following-sibling-or-self and > preceding-sibling-or-self could be justified , then we > should also have self version for child, following, > parent and preceding Axes (i.e. child-or-self, > following-or-self, parent-or-self and > preceding-or-self) ! > > Probably, adding so many additional -or-self Axes will > confuse users; so it will be best, if we should > deprecate existing descendant-or-self and > ancestor-or-self Axes .. (a workaround with union > operator will still work).. > > Regards, > Mukul > > > > > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile phone. > http://mobile.yahoo.com/maildemo > >
Received on Wednesday, 16 February 2005 17:18:17 UTC