-----Original Message-----
From: Graydon graydon(_at_)marost(_dot_)ca [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
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--