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 19:21:56 UTC