xsl-list
[Top] [All Lists]

Re: [xsl] Pattern notation for preceding-sibling

2014-08-12 20:08:14


-----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
--~--

<Prev in Thread] Current Thread [Next in Thread>