[Top] [All Lists]

[xsl] Re: [saxon] Predicates order of evaluation

2020-09-19 02:37:24

Bad example. Here's the real thing. I found myself having to write

[A] if (parent::*) then $fRename(name(..),..) else ()  

instead of 

 [B] $fRename(name(..),..) [parent::*] at a pinch I should possibly be able 
to write

 [C] $fRename(name(..),..) [current()/parent::*]  in which case the predicate 
is not dependent on the evaluating the expression.

[A] tests whether the context item has a parent node, [B] tests whether the 
result of calling $Rename() has a parent node, so they are completely different 

[C] (which I've corrected to make current() a function call) is semantically 
equivalent to [A] except that the spec guarantees in the case of [A] that the 
call on $fRename will not be evaluated (i.e. will not have any errors or 
side-effects) if the condition is false, and there is no such guarantee for [C].

Michael Kay

I've taken this off the Saxon list, since having a thread on two lists with 
overlapping membership must be irritating people, and is generally disapproved.

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>
  • [xsl] Re: [saxon] Predicates order of evaluation, Michael Kay mike(_at_)saxonica(_dot_)com <=