[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XPath 2.0 - how much of XQuery should it include?

• To: Uche Ogbuji <uche.ogbuji@f...>
• Subject: Re: XPath 2.0 - how much of XQuery should it include?
• From: Jeni Tennison <jeni@j...>
• Date: Fri, 10 May 2002 10:23:25 +0100
• Cc: Jonathan Robie <jonathan.robie@d...>, xml-dev@l...
• In-reply-to: <200205100510.g4A5AB309693@l...>
• Organization: Jeni Tennison Consulting Ltd
• References: <200205100510.g4A5AB309693@l...>
• Reply-to: Jeni Tennison <jeni@j...>

Uche wrote:
> I agree with most of your post Jeni. The one thing that would be
> nice to see introduced into XPath is some sort of shortcutting in
> certain operators (either the boolean operators, or with an
> introduced ternary operator). XPath 2.0's if expressions provide
> this. If course, short-cutting is really much nicer and safer in a
> side-effect-free language, so XPath 2.0 manages to chuck this
> advantage as well.

"Shortcutting" means that you only evaluate the first part of the
expression if you can determine the result of the expression, correct?
In XPath 1.0, 'and' and 'or' are shortcutting:

  An or expression is evaluated by evaluating each operand and
  converting its value to a boolean as if by a call to the boolean
  function. The result is true if either value is true and false
  otherwise. **The right operand is not evaluated if the left operand
  evaluates to true.**

  An and expression is evaluated by evaluating each operand and
  converting its value to a boolean as if by a call to the boolean
  function. The result is true if both values are true and false
  otherwise. **The right operand is not evaluated if the left operand
  evaluates to false.**

I hadn't noticed that this changes in XPath 2.0 (it's not listed as
one of the incompatibilities):

  The order in which the operands of a logical expression are
  evaluated is implementation-dependent. The tables above are defined
  in such a way that an or-expression can return true if the first
  expression evaluated is true, and it can return the error value if
  the first expression evaluated contains an error. Similarly, an
  and-expression can return false if the first expression evaluated is
  false, and it can return the error value if the first expression
  evaluated contains an error.

Basically, implementations are free to implement it as a shortcut, or
free not to. Which means that anyone who has taken advantage of the
shortcutting in XPath 1.0, or who takes advantage of the shortcutting
available in a particular implementation of XPath 2.0, is likely to
run into problems. For example, if someone has:

  function-available('my:boolean-function') and my:boolean-function()

then they might now get an error where they didn't before. If someone
has:

  *[simple-filtering-expression or complex-filtering-expression]

then their performance might be hit.

I agree completely that something similar to the if expression in
XPath 2.0 is required. I don't like if/then/else because it encourages
people to use XPath 2.0 as a language in its own right, but I'd rather
have that than no conditional expression at all.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

• Follow-Ups:
  • RE: XPath 2.0 - how much of XQuery should it include?
    • From: "Michael Kay" <michael.h.kay@n...>
  • Re: XPath 2.0 - how much of XQuery should it include?
    • From: Uche Ogbuji <uche.ogbuji@f...>

• References:
  • Re: XPath 2.0 - how much of XQuery should it include?
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: RE: PSVI formalization
• Next by Date: Re: XPath 1.5? (was RE: typing and markup)
• Previous by thread: Re: XPath 2.0 - how much of XQuery should it include?
• Next by thread: Re: XPath 2.0 - how much of XQuery should it include?
• Index(es):
  • Date
  • Thread