Re: [xml] Regarding xmlTextReaderNext Api: PATCH

On Wed, Jul 02, 2008 at 03:08:59PM +0800, Ashwin wrote:

 ah, then it's a bug. i have tried to make sure the reader and the
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

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

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

Please let me know if this is correct, or some modifications are required

  That looks correct, I looked at it last week, applied it to my tree
and commited it to SVN yesterday,

  thanks !


Daniel Veillard      | libxml Gnome XML XSLT toolkit
daniel veillard com  | Rpmfind RPM search engine | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]