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

RE: XML design of ((a and b) or c)

• From: "Michael Kay" <mike@s...>
• To: "'Rick Marshall'" <rjm@z...>,"'Ken North'" <kennorth@s...>
• Date: Fri, 15 Dec 2006 11:35:10 -0000

> However the other side effect is also interesting and 
> important - the ability to not evaluate something once a 
> condition has been determined (or  indeed force evaluation). 
> At the moment I believe XSLT is required for that.

I'm glad someone brought the discussion back to XML.

In XPath 1.0 the "and" operator has short-cut semantics: given (A and B), B
is not evaluated if A is false. However, it's almost impossible to write
code that depends on this, because (1) evaluating A cannot have any
side-effects that influence the evaluation of B, and (2) there are very few
expressions in XPath 1.0 that can cause dynamic errors.

In the new round of specs this has changed so that the order of evaluation
of arguments is explicitly implementation-dependent. The reason for this is
to allow optimization of predicates (and where clauses in XQuery) to use
indexes: given //x[age < 100 and name="Snelsdon"] you want to be able to use
an index on name if one is available. This means you can't safely use the
first condition to mask errors that might occur in the second, as in

//x[(y castable as xs:integer) and (xs:integer(y) > 100)]

Instead you have to write:

//x[if (y castable as xs:integer) then (xs:integer(y) > 100) else false()]

In fact, you can't even safely write 

//x[y castable as xs:integer][xs:integer(y) > 100]

(I won't try to defend that decision)

Michael Kay
http://www.saxonica.com/

• Follow-Ups:
  • RE: XML design of ((a and b) or c)
    • From: "Michael Kay" <mike@s...>

• References:
  • Re: XML design of ((a and b) or c)
    • From: Rick Marshall <rjm@z...>