ah, then it's a bug. i have tried to make sure the reader and the
walker
work the same, but i think I didn't tried that extensively for extra functionality like skipping part of the tree. Can you see why xmlTextReaderNextTree doesn't work, it seems it should do what is expected, i don't really see why not.I think the functionality to skip the subtree is missed, will try and add that, iterative code like in the one for xmlTextReaderNext is not present
Hi Daniel,
I am attaching a patch for the above problem, now the behaviour is pretty
similar to what is expected, there is however a doubt in one case, the case
where the node on which the API is called does not have a sibling. Assume
the following doc :-
<root>
<parentelement>
<element1>
<subtree>
</element>
<element2>
<subtree>
</element2>
<element3>
<subtree>
</element3>
</parentelement>
<siblingnode/>
</root>
If I call the xmlTextReaderNext on element3 for pre-parsed documents, with
the fix I return the next node as the <siblingnode>. However, for
non-preparsed docs the node is returned <parentelement>, I am guessing the
end element node of parentelementnode if viewed in document order.
IMO for xmlTextReaderNextTree, the appropriate node returned is the sibling
node. So I have based the fix on the logic that after a call to
xmlTextReaderNextTree, the code will check if a sibling is present for that
particular node, move to that node if present, else move to the parent and
check for sibling and if present move to that node and return, else repeat
the process....
Note: In the example quoted suppose <siblingnode> is absent, then with the
attached fix, the Api will return 0, ie node not found, if called on
<element3>.
Please let me know if this is correct, or some modifications are required
Thanks!!
Regards
Ashwin
Attachment:
patch.txt
Description: Text document