xsl-list
[Top] [All Lists]

Re: [xsl] XPath expression to check that there are no intervening elements?

2016-07-19 13:26:17
"Claimed as fastest", Dimitre?

No, I was just wondering if it would be fastest, in both XSLT 1 and XSLT 2 (I wasn't being specific, it might be true for both), when using only the axes and without looking backwards.

Personally, I like finding solutions that are XPath pure without "thinking like a programmer" when using functions such as count() and expressions that appear to be mimicking the use of other programming languages. If it is an expression that cannot be written using other programming languages, then it is something to learn from for people unfamiliar with XPath.

Certainly your suggestion is XPath pure by using document order tests, again getting away from function calls that do counting or using an expression that might also be found in other programming languages.

As for any claim, I'll let smarter people than me tell me if what I posit will actually be faster or not. It just feels to me that there isn't any revisiting of nodes in my expression: stop at the first B, continue to the first non-B and stop, then continue to the first next B and stop (because of the boolean not()), without needing to visit any node more than once.

. . . . . . . Ken

At 2016-07-19 17:45 +0000, Dimitre Novatchev dnovatchev(_at_)gmail(_dot_)com 
wrote:

To summarize, we seemingly have this:

Shortest (XPath 2.0):

 B and not(*[. >> ../B[1] and . << ../B[last()]][not(self::B)])


Claimed as fastest (XPath 1.0):

B and not(B[1]/following-sibling::*[not(self::B)][1]/following-sibling::B)


Both of these have the same worst-case execution time -- when there is
no B, or where the block of Bs is the tail of the sequence of
siblings.

The latter expression will be significantly faster in cases of long
sequence of siblings and short block of Bs at the start of the
sequence.


On Tue, Jul 19, 2016 at 9:44 AM, G. Ken Holman 
g(_dot_)ken(_dot_)holman(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
> Okay ... I wonder if this might be fastest of all:
>
>   B  and  not(
> B[1]/following-sibling::*[not(self::B)][1]/following-sibling::B )
>
> for "there is a B, and starting from it there is no following sibling non-B
> that has a following sibling B.  No counting and no looking backwards.
>
> . . . . . . Ken
>
> At 2016-07-19 16:36 +0000, Dimitre Novatchev dnovatchev(_at_)gmail(_dot_)com 
wrote:
>
>> To avoid the false true when there are no Bs at all:
>>
>>
>> XPath 1.0:
>> B and not(B[1]/following-sibling::node()[not(position()  >
>> ../count(B))][not(self::B)])
>>
>>
>> XPath 2.0:
>> B and not(node()[. >> ../B[1] and . << ../B[last()]][not(self::B)])
>>
>> On Tue, Jul 19, 2016 at 9:29 AM, Dimitre Novatchev 
<dnovatchev(_at_)gmail(_dot_)com>
>> wrote:
>> > XPath 1.0:
>> >
>> >  not(B[1]/following-sibling::node()[not(position() >
>> > ../count(B))][not(self::B)])
>> >
>> > XPath 2.0:
>> >
>> > not(node()[. >> ../B[1] and . << ../B[last()]][not(self::B)])
>> >
>> > Cheers,
>> > Dimitre
>> >
>> > On Tue, Jul 19, 2016 at 9:16 AM, G. Ken Holman 
g(_dot_)ken(_dot_)holman(_at_)gmail(_dot_)com
>> > <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
>> >> I like Mike's answer for XSLT 2.
>> >>
>> >> Your XSLT 1 solution can be improved by reducing the number of counting
>> >> actions.  Your solution has three uses of count() ... this has only
>> >> two:
>> >>
>> >>   count(B[last()]/preceding-sibling::*[not(self::B)]) =
>> >>   count(B[1]/preceding-sibling::*[not(self::B)])
>> >>
>> >> Avoiding the use of counting you could do the following:
>> >>
>> >>   string( generate-id( B[1]/preceding-sibling::*[not(self::B)][1] ) ) =
>> >>   string( generate-id( B[last()]/preceding-sibling::*[not(self::B)][1]
>> >> ) )
>> >>
>> >> The use of string() is necessary in case the sequence of children
>> >> starts
>> >> with B.
>> >>
>> >> Come to think of it, neither your answer, Mike's answer nor my answer
>> >> will
>> >> work if there are no B children at all.  You will get a false positive.
>> >> Does your test need to accommodate that situation?
>> >>
>> >> . . . . . . . . Ken
>> >>
>> >> At 2016-07-19 15:44 +0000, Costello, Roger L. 
costello(_at_)mitre(_dot_)org wrote:
>> >>>
>> >>> Hi Folks,
>> >>>
>> >>> This XML has a solid block of <B> elements:
>> >>>
>> >>> <Document>
>> >>>     <A/>
>> >>>     <B/>
>> >>>     <B/>
>> >>> </Document>
>> >>>
>> >>> This XML has an intervening <C> element:
>> >>>
>> >>> <Document>
>> >>>     <A/>
>> >>>     <B/>
>> >>>     <C/>
>> >>>     <B/>
>> >>> </Document>
>> >>>
>> >>> I need an XPath expression to return a Boolean value:
>> >>>
>> >>>         Return true if there is one solid block of <B> elements
>> >>>                 (no intervening elements).
>> >>>         Otherwise, return false.
>> >>>
>> >>> I created a horrendous XPath expression to solve it:
>> >>>
>> >>> count(B) eq (B[last()]/count(preceding-sibling::*)+1 -
>> >>> B[1]/count(preceding-sibling::*))
>> >>>
>> >>> Can you provide a better (simpler, more efficient) XPath expression?
>> >>>
>> >>> /Roger
>> >>>
>


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/s/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ 
mailto:gkholman(_at_)CraneSoftwrights(_dot_)com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--~----------------------------------------------------------------
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>