- From: Michael Kay <mike@saxonica.com>
- Date: Thu, 3 Dec 2020 06:53:10 +0000
- To: Joel Kalvesmaki <kalvesmaki@gmail.com>
- Cc: public-xslt-40@w3.org
- Message-Id: <CBD10D99-E44F-4B28-834E-6FDAEA958FE9@saxonica.com>
> OTOH, I have often wanted an easier XPath way to construct the equivalent of JQuery nextUntil() and prevUntil() -- that would be another topic I suppose.
The current 4.0 proposal is
items-until(following-sibling::*, ->{@class="note"})
to select all following siblings until (and including) the first where @class="note". Variants items-before, items-after, and items-from are also offered.
With keyword arguments we could now consider repackaging these four functions as one, for example
select-range(following-siblings::*, until := ->{@class="note"})
which would allow both starting and ending conditions in a single call
select-range(following-siblings::*, from := -> {@marker='begin'}, to := ->{@marker='end'})
Could also combine this with the proposed slice() function:
select-range($input, start := 10, end := 3, step := -1)
And the equivalent of subsequence could be thrown into the mix:
select-range($input, start := 10, length := 4)
I'm not entirely convinced by the merits off such all-encompassing functions. There's a useful design principle that a function should do precisely one thing, and do it well, and that different things should be done by different functions. There's a balance somewhere. But the ability to define different starting and ending conditions for a range, and use them in arbitrary combinations, does have some appeal.
Michael Kay
Saxonica
> On 3 Dec 2020, at 04:33, Joel Kalvesmaki <kalvesmaki@gmail.com> wrote:
>
> From my perspective, the difference between next and following, previous and preceding would introduce confusion, since in common usage each pair of terms is generally regarded as synonymous.
>
> OTOH, I have often wanted an easier XPath way to construct the equivalent of JQuery nextUntil() and prevUntil() -- that would be another topic I suppose.
>
> jk
>
> On Wed, Dec 2, 2020 at 10:11 AM Dimitre Novatchev <dnovatchev@gmail.com <mailto:dnovatchev@gmail.com>> wrote:
> > An alternative would be to introduce new functions:
> >
> > fn:next-sibling($node as node()?) as node()?
> > fn:previous-sibling($node as node()?) as node()?
>
>
> +1 for the functions vs. new axes.
> This can be conveniently combined with the arrow operator:
>
> $myXpathExpressionSelectingNode => next-sibling()
>
> Thanks,
> Dimitre
>
> On Wed, Dec 2, 2020 at 2:08 AM Christian Grün <cg@basex.org <mailto:cg@basex.org>> wrote:
> 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 <mailto: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 <mailto:norm@saxonica.com>> wrote:
> >
> > Michael Kay <mike@saxonica.com <mailto: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
> >
> >
>
>
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> To avoid situations in which you might make mistakes may be the
> biggest mistake of all
> ------------------------------------
> Quality means doing it right when no one is looking.
> -------------------------------------
> You've achieved success in your field when you don't know whether what you're doing is work or play
> -------------------------------------
> To achieve the impossible dream, try going to sleep.
> -------------------------------------
> Facts do not cease to exist because they are ignored.
> -------------------------------------
> Typing monkeys will write all Shakespeare's works in 200yrs.Will they write all patents, too? :)
> -------------------------------------
> Sanity is madness put to good use.
> -------------------------------------
> I finally figured out the only reason to be alive is to enjoy it.
>
>
>
> --
> Joel Kalvesmaki
> kalvesmaki.com <http://kalvesmaki.com/>
Received on Thursday, 3 December 2020 06:53:28 UTC