OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] XML design of ((a and b) or c)

> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS