Re: New axes?

An alternative would be to introduce new functions:

  fn:next-sibling($node as node()?) as node()?
  fn:previous-sibling($node as node()?) as node()?

Similar to fn:has-children, we cannot perform straightforward node
tests. The requirement for such tests may depend on the use cases we
are trying to solve.
____________________________________

On Wed, Dec 2, 2020 at 10:51 AM Michael Kay <mike@saxonica.com> wrote:
>
> It's a fairly cosmetic change to get rid of a minor ugliness. People often forget the [1] qualifier when they only want the immediately following sibling, and the difference between preceding-sibling::*[predicate][1] and preceding-sibling::*[1][predicate] isn't intuitive.
>
> The problem of course is that you can never get rid of a danger point on a well-trodden road by providing a new shiny road; the very people who fall into the trap will be unaware of the new features.
>
> Michael Kay
> Saxonica
>
> On 2 Dec 2020, at 09:38, Norm Tovey-Walsh <norm@saxonica.com> wrote:
>
> Michael Kay <mike@saxonica.com> writes:
>
> How would anyone feel about adding new axes next::* and previous::* to
> get the first following/preceding sibling?
>
> Or next-sibling / previous-sibling if people prefer long names.
>
> It would have to be that next::* means following-sibling::*[1]
>
>
> Can next::* ever be different from (following-sibling::*)[1]?
>
> Another two candidates are following-sibling-or-self::* and
> preceding-sibling-or-self::*, with hopefully obvious semantics.
>
>
> What are the use cases for these?
>
> To me, it feels like adding a new axis is a fairly heavyweight change.
> There are already quite a few axes and I think users sometimes struggle
> to understand them. I’m not saying we must not add new axes, but I’d
> like to be convinced that their utility justifies them.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
>

Received on Wednesday, 2 December 2020 10:08:22 UTC