RE: following/preceding-sibling shorthands in XPath 2.0

> I think that a lot of people feel that XPath syntax is terse enough already,
> and there will be little enthusiasm in the working groups for the
> introduction of further abbreviations. You can always create functions
> z:next(.) and z:prior(.) if you really need to save keystrokes.

I don't think the point of a terse syntax is necessarily to save keystrokes.
More important is readability. While XPath syntax is well defined, the
unabbreviated syntax is pretty tough sledding for mere mortals, like
myself, and the presence of unabbreviated syntax in the middle of
a bunch of location steps, definitely slows me down. Adding functions
only solves part of the problem, as it makes the programmer scanning
the code have to worry about what the heck the function does.

While you're correct about the problem with using the unary operator
for following-sibling and previous-sibling axes, it also strikes me
as a bit bizarre that such important axes don't have an abbreviated syntax.

Thanks,
Alex Kodat
Sirius Software

Note: I've cc'ed [email protected] as Paul Cotton suggested.
      Sorry if I shouldn't have cc'ed [email protected].
      Or maybe I shouldn't have cc'ed the former because the original
      note didn't go there?