RE: Contents of WHERE a predicate?

I guess another take on that is that the WHERE acts to prune -- or not -- a
variable after it's been bound. If the predicate test is true, the variable
is returned. If the test is false, it isn't. A bound nodeset is thus
returned in its entirety -- at least in a LET -- or not at all. Thanks for
the perspective.

Howard

> -----Original Message-----
> From: Michael Rys [mailto:mrys@microsoft.com]
> Sent: Tuesday, April 24, 2001 3:49 PM
> To: Howard Katz; Evan Lenz; www-ql@w3.org
> Subject: RE: Contents of WHERE a predicate?
>
>
> This is a "variable" binding issue:
>
> >      LET $book := //book[  title = 'Data on the Web'  ]
> >      RETURN
> >             $book
>
> Here the binding is that //book[title = 'Data on the Web'] will bind all
> books that satisfy the predicate to the $book variable.
>
> >     LET $book := //book
> >     WHERE $book/title = 'Data on the Web'
> >     RETURN
> >            $book
>
> Here all books are bound to $book. Thus all books will be returned.
>
> Since variables can only be assigned once and no side-effects can occur,
> you can basically interpret their semantics as a common subexpression
> replacement.
>
> Thus the first query becomes:
>
> >      RETURN
> >             //book[  title = 'Data on the Web'  ]
>
> The second
>
> >     WHERE //book/title = 'Data on the Web'
> >     RETURN
> >            //book
>
> You want to bind a single book to a bound variable and then only return
> it if it satisfies the predicate and then iterate over all books:
>
> FOR $book in //book
> WHERE $book/title = 'Data on the Web'
> RETURN $book
>
> Best regards
> Michael
>
> > -----Original Message-----
> > From: Howard Katz [mailto:howardk@fatdog.com]
> > Sent: Tuesday, April 24, 2001 3:27 PM
> > To: Evan Lenz; www-ql@w3.org
> > Subject: 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 22:16:07 UTC