search

w3c / qt3tests

Tests for XPath and XQuery
27 stars 17 forks source link

fn:root. alternative solutions for pre-evaluated expressions #12

Closed ChristianGruen closed 4 years ago

ChristianGruen commented 4 years ago

Thanks for your assessment. In some XQuery processors (including the latest versions of Saxon and BaseX), the following expressions…

exists(1 = fn:root(1[. = 1])),
1 = (1, fn:root(1[. = 1]))

…yield true(), so I assumed that pre-evaluations (which are based on the static types of the arguments/operands) are covered by the optimization section of the specification. Good to know I got it wrong.

If the behavior of Saxon turns out to be wrong, do you want me to file an issue for this bug?

ChristianGruen commented 4 years ago

Related: Saxon seems to return true() for root() instance of node(), even if no context is available. I guess this is illegal, too?

ChristianGruen commented 4 years ago

…and yet another one: (1, <_/>) ! exists(root()); the current result is true true (not only in Saxon).

michaelhkay commented 4 years ago

OK, I see now what your logic is. Unfortunately the whole "errors and optimization" scene is riddled with problems like this: the theoretical foundations are very weak. The reasoning, I guess, is that in the expression E[root()], the EBV of the predicate can only be true or an error, therefore it is legitimate to assume true. I'm surprised that Saxon should ever allow root(1) - I would have thought that would be thrown out by static analysis; but I guess there are cases where the static analysis will be bypassed if the outcome isn't needed. Reluctantly, I think I have to agree that your analysis is correct. (I've argued in the past though that we need to draw a line somewhere. The "Errors and Optimization" rules allow a processor to deliver almost any result it feels like.)

michaelhkay commented 4 years ago

By the way, I found your phrase "pre-evaluated expressions" somewhat confusing here. The specific concern here is with inferring the result of an expression where only the type of one of its subexpressions needs to be known, not its actual value (neatly illustrated by the "root() instance of node()" example). It's clear that the current rules allow this ("a processor is able to establish that there are only two possible outcomes of evaluating Q, namely the value V or an error"); it's not clear that it's a good idea.