Hi Eliot, > In terms of processing optimization, is there any reason to prefer one > formulation over the other (meaning, is it possible to predict how XPath > processors will be able to optimize this type of expression)?
I like Ken's solution, but mostly because it's more concise. You will never know what a specific implementation does, or what it will do in a future version. It also depends on your data: If you have deep document structures, the ancestor step may get more expensive. Just create some gigabytes of test data and do some simple testing with the processors of your choice. However, your original query may be evaluated faster by some processors if you move the path expression out of the predicate and bind it to an additional variable: let $a1 := $doc/a let $a2 := $a1//a let $bsInA1 := $a1//b[not(ancestor::a = $a2)] Cheers, Christian _______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
