RE: [XPath]Need of another Axes!

Hello Mr. Kay,
  Thanks for your response. I am happy that you agree
with my point. 

If the descendant-or-self and ancestor-or-self axes
are deprecated in XPath 2.0, the Axes definitions will
be cleaner. I feel, this change will not cause much
problem for the user community, as well as for the
XSLT processor vendors. If a person has worked a lot
with XSLT 1.0, and is transitioning to XSLT 2.0, if he
finds that these 2 axes are deprecated, he can use the
union operator workaround without much difficulty. The
deprecation of these 2 axes can be specified as
implementation defined. The spec may specify the union
workaround as a note. 

I hope you would agree, the goal of XSL WG is to
introduce new useful features in the language, as well
as produce a great language spec. 

If omiting these 2 axes will make the language spec
better(i.e. the academic output), and is causing no
problems to users, and would involve not much problems
for vendors, it might be considered by the WG at this
stage.

Regards,
Mukul     

--- Michael Kay <mhk@mhk.me.uk> wrote:

> 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 
> > 
> > 
> 
> 
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250

Received on Wednesday, 16 February 2005 18:07:57 UTC