RE: Contents of WHERE a predicate?

Hi Evan,

Maybe I wasn't clear enough. I'm trying to understand how two LET queries
differ, when one uses an inline XPath predicate,

     LET $book := //book[  title = 'Data on the Web'  ]
     RETURN
            $book

and the other uses a WHERE:

    LET $book := //book
    WHERE $book/title = 'Data on the Web'
    RETURN
           $book

I'm trying to see if there's anything interesting or significant to be
learned when that's the only distinction between the two. If you change one
of the LET statements to a FOR, then that's a different problem and not the
one I'm looking at here.

Howard

> -----Original Message-----
> From: www-ql-request@w3.org [mailto:www-ql-request@w3.org]On Behalf Of
> Evan Lenz
> Sent: Monday, April 23, 2001 11:52 PM
> To: Howard Katz; www-ql@w3.org
> Subject: 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 18:26:36 UTC