[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Is the semantics of the "or" operator implementation-dependent?


Subject: Re: [xsl] Is the semantics of the "or" operator implementation-dependent?
From: "Abel Braaksma (Exselt) abel@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 16 Sep 2014 12:57:52 -0000

> -----Original Message-----
> From: Costello, Roger L. costello@xxxxxxxxx [mailto:xsl-list-
> service@xxxxxxxxxxxxxxxxxxxxxx]
>
> Hi Folks,
>
> Upon experimentation I discovered that Saxon has this behavior:
>
> 	false() or error()  	raises an error
> 	error() or false()	raises an error
> 	true() or error()	returns true
> 	error() or true()	returns true
>
> Will every XSLT processor (XPath engine) have the same behavior as Saxon?

Not necessarily. Short-circuiting expressions in more complex ones (like "some
$x in y/z satisfies $x[boolean(bar) or error()][foo]" may never return an
error if the processor can, perhaps statically, determine that there is no
node that has a child "foo", so it never returns anything. A better example
with casting is given at the bottom of:
http://www.w3.org/TR/xpath20/#id-errors-and-opt.

However, expressions with "or" have left-to-right associativity. I am not sure
that that means that left-to-right evaluation is a requirement, though. I am
sure that processors can short-circuit expressions as they see fit. This means
that

- these are processor dependent:
true() or error()	returns true
error() or true()	returns true

In the Exselt processor, we short-circuit from left to right, which means that
the first raises no error, but the second does.

- there are processor independent (because "or" requires if one operand is
false that it must evaluate the other part)
false() or error()  	raises an error
error() or false()	raises an error

You can, however, rewrite such expressions, as also explained in the section
in the XPath 2.0 spec above (same holds for XPath 3.0) in such a way that
order of execution is defined. I.e. with an if-then statement. This would also
make your intend clearer to fellow programmers.

>
> That last sentence leads me to think that an XSLT processor could have this
> behavior:
>
> 	true() or error()	raises an error
> 	error() or true()	raises an error
>
> Are there any XSLT processor (XPath engine) with this behavior?

Yes for the second (Exselt), the first: not that I am aware of. However, if
your expression were written like this:

doc('test.xml')/foo/bar or error()

a smart processor might consider the lh-side operand to be a costly operation,
and process the rh-side operand first. Again, you should rewrite such
expressions if you want the error-case to be predictable.

>
> Is the semantics of the "or" operator implementation-dependent?
>

No, the semantics not, the order of execution is, however, which means that in
error-cases, you can have different outcomes between processors. This is not
different from other languages, in C#, F#, Java, C++ similar forms of
optimization exist.

If you want to deterministically throw an error, use a more predictable way of
writing. I don't think I have ever come across a C++ style of code like this
(and even if you see it, it is considered code smell):

return a || functionThrowingException()

Instead, people tend to write:

return a ? a : functionThrowingException()

which is the equivalence of the if-then syntax in XPath.

Cheers,

Abel Braaksma
Exselt XSLT 3.0 streaming processor
http://exselt.net


Current Thread
Keywords