Re: [xsl] Pattern notation for preceding-sibling

["Abel Braaksma (Exselt) abel@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Graydon graydon@xxxxxxxxx [mailto:xsl-list-
> Subject: Re: [xsl] Pattern notation for preceding-sibling
>
> On Tue, Aug 12, 2014 at 10:50:37PM -0000, Heiko Niemann kontakt@heiko-
> niemann.de scripsit:
> > >> /foo/E/preceding-sibling::(A,N)
> > >
> > > Indeed, this is currently disallowed syntax.
> > >
> >
> > Is there a discussion to allow this syntax?
>
> Does that mean I'm looking for /foo with children (in document order) A, N,
> and E, or does it mean I'm looking for /foo with an E child preceded by an A
or
> an N child?  I suspect you mean the latter from the other examples of what
> you're trying to do, but if we're really saying "preceding-sibling this
> sequence" it should be the first one.

I wouldn't be surprised if some discussion on this has been going on in the
working groups in the past. My gut feeling is the same as Graydon's, the
parenthesized expression usually denotes a sequence and if any sequence where
allowed in preceding-sibling::(A, N), I don't know what it would mean if you
were to write ($A), (1 to 4) or (for $i in A return name($i)).

But if we consider giving this parenthesized syntax a special meaning *and* if
the XPath EBNF allows this syntax unambiguously, one could formalize it
something like:

ParenthesizedAxisStep ::=
        (ForwardAxis | ReverseAxis)  "("  NodeTest  ("," NodeTest)* ")"

And then say that a ParenthesizedAxisStep is an abbreviated combination of the
union of axis steps, taking the axis and combining them with the union
operator. Preceding-sibling::(A, N) is then expanded to (preceding-sibling::A
| preceding-sibling::N) (including parentheses).

But considering the complexity of the EBNF and considering the relatively
small relief this will give programmers, I'm not sure there will be many votes
supporting this syntax. Though I understand the use-case for it, and esp. in
complex expressions it could actually make the syntax cleaner.


>
> I can imagine that would be useful, but possibly not useful enough to
> implement.  (What does ancestor::(A,B,C) mean?)
>

Given the expansion I suggested above, this would mean (ancestor::A |
ancestor::B | ancestor::C). Which I think is consistent.

If you want to pursue this idea, it is always possible to raise a bug-report
against the XPath 3.0 (or 3.1) spec, which usually results in the group
discussing the proposal, but (of course) gives no guarantee that it will
actually be implemented.

Cheers,
Abel