> Any estimate on the Sorted Iterator issue ??
OK, I think I have a plan of action. I'm writing it down first to see if
it makes sense to me, and, of course, to anyone else.
On AxesWalker and DTMIterator, declare methods called
isChildOrAttributeInDocOrder() (for lack of a better name). In
FilterExprWalker#isChildOrAttributeInDocOrder(), return
m_nodeSet.isChildOrAttributeInDocOrder(). This means that
FilterExprWalker#isChildOrAttributeInDocOrder() can only be called after
FilterExprWalker#setRoot(int root) has been called so that m_nodeSet is set
properly. The rest of the walkers can return a static value. This works
because a FilterExprWalker can only occur at the head of the location
path... so it can be treated a bit differently.
In WalkingIteratorSorted#setRoot, before collecting the sorted node-set, if
all walkers return true for isChildOrAttributeInDocOrder(), then we know
that the step iteration will return all the nodes in document order
naturally. Therefore, in this case, we can act like a WalkingIterator
instead of a WalkingIteratorSorted.
Note that normally the need for sorting can be determined statically in
WalkerFactory. The problem is caused by a filter expression which can
start with either a variable or an extension, in which case, we can't tell
if sorting needs to be done until runtime.
Note that a function that returns NodeSetDTM will always be sorted, because
in this case it will be hard to determine if the set is sorted and contains
nodes that will produce a naturally sorted list when steps are applied.
Just using isChildOrAttributeInDocOrder() will still cause some location
paths to be sorted, that don't need to be. But I think that
isChildOrAttributeInDocOrder() will cover most of the cases we care about
for now, and I would prefer keeping things simple.
Does anyone who understands what I said above think this makes sense or
not?
-scott
