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

[Kasimier Buchcik <kbuchcik 4commerce de>]

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.

Regards,

Kasimier

[1] 
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1312295772
[2] 
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1950641247