You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't know if this is an issue because I'm not 100% familiar with XML specifications, but I don't seem to be able to know where the val is in relation to the children, for example for this xml string
<some>
<child> first child val </child>
some val
<child>second child val</child>
</some>
seems to give no indication where some val is, and if the string is like this
<some>
<child>first child val</child>
some val
<child>second child val</child>
some more val
</some>
some val is completely ignored in favor of some more val.
The text was updated successfully, but these errors were encountered:
So you are correct, this is valid XML. But xmldoc doesn't support this kind of "mixed content" in favor of the simplicity of the val property. Otherwise you'd have to write node.children[0].val where the child is a text node, instead of the more intuitive node.val. Are you parsing HTML or XML?
I'm parsing XML from an open document format file. To be clear I haven't actually run into mixed content, but I don't know if I will get mixed content too, though I think it's unlikely. What I'm more worried about is the first case where I don't know if some val comes after the first child.
Yeah, that information will unfortunately be lost by xmldoc. You could probably make some simple modifications to the library to retain the text nodes as additional children, or you might investigate a more full-featured library like node-elementtree.
I hope this answers your original question - closing this issue for now!
I don't know if this is an issue because I'm not 100% familiar with XML specifications, but I don't seem to be able to know where the val is in relation to the children, for example for this xml string
seems to give no indication where some val is, and if the string is like this
some val is completely ignored in favor of some more val.
The text was updated successfully, but these errors were encountered: