RE: Contents of WHERE a predicate?

Hi Howard,

I can't speak for the Query WG, but I think you're a little off-base here.
The "same query in WHERE form" is not what you show, but this instead:

LET $book := //book
FOR $b IN $book
WHERE $b/title="Data on the Web"
RETURN $b

This iterates through each member of //book, evaluating the WHERE clause
each time, just as a predicate applied to that expression would. The example
you gave does no such iteration and thus evaluates WHERE only once, which
means that, yes, you're selecting all title elements at once, and it will
return true if the value of any one of those title elements is "Data on the
Web". The difference is that in the above, $b is bound to one node (like the
"current node" in XSLT) and the comparison takes place on the title
element(s) of one book element at a time.

Hope this helps,
Evan


Howard Katz wrote:
> Is the contents of a WHERE clause formally categorized as a predicate? And
> if so, is this different from an inline XPath predicate? Specifically, I'm
> wondering what to do in the following case, where the use of a string
> equality test in a WHERE clause produces a markedly different result from
> its use inline, depending on how the contents of the WHERE is to be
> interpreted.
>
> To wit, the query:
>
>      LET $book := //book[  title = 'Data on the Web'  ]
>      RETURN
>             $book
>
> would seem, both by common sense and by the definition in Section 2.4
> (Predicates) of the XPath specification, to return the third book in
> "bib.xml". Section 2.4 refers to a predicate expression being evaluated
> successively against each node in the nodeset under test, with only those
> nodes that succeed against the test being retained.
>
> Section 3.4 (Booleans) on comparisons, on the other hand, says that if a
> nodeset is compared against a string, the result is true if the result of
> comparing even a single node in the nodeset against the string
> evaluates to
> true.
>
> Given that, the result of recasting the same query in WHERE form:
>
>     LET $book := //book
>     WHERE $book/title = 'Data on the Web"
>     RETURN
>            $book
>
> would seem to bring about the rather odd result of returning all
> 4 books in
> the file, if the condition in the WHERE is seen as a comparison
> and not as a
> predicate: The comparison evaluates to true because of 3.4, and the RETURN
> statement gets executed, returning the entire nodeset.
>
> Is this how the contents of the WHERE is to be interpreted then: as a
> comparison? The most straightforward implementation of the
> grammar certainly
> seems to favour the "comparison" approach, although it wouldn't be overly
> difficult to implement the "predicate" interpretation instead.
>
> Or can we simply call the comparison a predicate on $book/title and return
> the more intuitive result? But then again, it might also seem odd
> to assign
> $book to initially be one thing -- the entire nodeset -- and then somehow
> magically transmute it en route, returning it as something else. Does that
> wreak havoc with the algebra? Or is it more an issue of maintaining
> consistency with XPath?
>
> Is this what Issue #24 [xquery-xpath-coercions] is talking about when it
> mentions non-intiuitve results and implicit existential quantification?
> Lovely expression, that. No wonder you people seem to be having
> such a good
> time. ;-)
>
> Howard

Received on Tuesday, 24 April 2001 02:45:44 UTC