Re: [xml] Possible bug on content addition then node deletion.

Hi Jose,

Jose Commins wrote:

Well, after testing and manual walking through the tree with a debugger, I noticed the difference - your code indeed works, and so does mine if I create the doc your way. But, I use xmlReadMemory in my code, and it produces this structure if I use the xml example as an input:

Which one?

NODE <Something> = (name->'Something', content->0):

NODE 'Dogs usually say bark but I say' = (name->'text', content->'Dogs usually bark but I say'):

....  and so on.

So xmlReadMemory does not join content to tags even if it is adjacent to them. Which explains the behaviour observed - the content ('Dogs usually say bark but I say') in your example actually *belongs*

No, in my example both text pieces are hold by adjacent text nodes;
please examine the resulting tree structure!

to 'Something' as content; with xmlReadMemory it isn't, it is separated into a separate text node.

This is an expected behaviour for a DOM tree; have a look at the
'Text' interface of the DOM API [1].

    I shall have to concatenate adjacent text nodes myself, then...

Concatenation of adjacent text nodes is done by xmlNodeGetContent.

The 'content' field for element nodes is always NULL.
Please have a look at the table describing the return values for
'nodeValue' for DOM [2], it reflects the 'content' field for libxml2
element nodes.

The behaviour of the xmlReader is correct here.



[1] [2]

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