I'm just thinking about some common cases like this...
* | @* | text()
Rather than building up an expression tree something like this... (in
pseudo-code)
UnionExpr
LocationPath
PredicateExpr( is element )
LocationPath
PredicateExpr( is attribute )
LocationPath
PredicateExpr( is text )
Where 3 seperate location path expressions are evaluated, we just hack the
expression simplify() methods so that UnionExpr tries to simplify & refactor
itself to something like this...
LocationPath
UnionPredicate
PredicateExpr( is element )
PredicateExpr( is attribute )
PredicateExpr( is text )
i.e. so that if the start of the location path is the same, as in the above
example, we just navigate once and union together the predicates.
Sure this only solves the problem for similar location paths, like
foo/a | foo/b
but I would think it will solve Geir's problem for sure. It would be a
fairly simple refactoring of the expression tree as well - and be more
optimal as it'd avoid unnecessary tree traversal..
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
