RE: Contents of WHERE a predicate? (fwd)

Sorry for mailing everyone, I think I prefer the following explanation,
for obvious reasons.. It is actually the same thing, just worded
slightly differently.

cheers and regards - murali.

---------- Forwarded message ----------
Date: Tue, 24 Apr 2001 16:14:30 -0700
From: Evan Lenz <elenz@xyzfind.com>
To: Murali Mani <mani@CS.UCLA.EDU>, Howard Katz <howardk@fatdog.com>
Subject: RE: Contents of WHERE a predicate?

Thanks Murali,

I should note that these issues are being addressed by the XSL and Query
WGs. See item 1.3 in section 2 of the XPath 2.0 Requirements document:
http://www.w3.org/TR/xpath20req

Evan

> -----Original Message-----
> From: Murali Mani [mailto:mani@CS.UCLA.EDU]
> Sent: Tuesday, April 24, 2001 3:46 PM
> To: Howard Katz
> Cc: Evan Lenz
> Subject: RE: Contents of WHERE a predicate?
>
>
>
> Hi,
>
> Let me try an explanation.
> Predicates can be applied to either node sets or to single nodes.
> Predicates applied to node sets return true based on XPath 1.0 -- i.e.,
> when one of the nodes in the node set satisfies the predicate.
> Predicates applied to a node returns true just like we compare two
> objects.
>
> I think the issue about intuition is definitely there, but I think it is
> ok that we accept the above definition as in XPath 1.0 for predicates
> applied on node sets.. (Yes, what you say might be more intuitive..)
>
> I think if we are really familiar with XPath 1.0 semantics, then we will
> not write such a query when the result expected is something else, as in
> your case.
>
> I am not sure if this kind of satisfies you, but I think the summary is --
> the question of intuition is definitely there, but I think there should be
> reasons why XPath 1.0 has the predicate definitions as it is presently --
> the experts should be able to help us here - or the designers just decided
> on one of the many options.
>
> <warning>speaking for himself only</warning>
>
> regards - murali.
>
> On Tue, 24 Apr 2001, Howard Katz wrote:
>
> > 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:53:53 UTC