According to the "Node Types" table on this W3Schools page, only the Document Node has a limit to the number of child Nodes (other than None!) of any one type:
The implication is that there can be any number of any other (listed) Child node in a Parent Node.
For many Nodes, that's a natural state:
An Element Node can have many other Child Element Nodes to define the complete Tree.
For some Nodes, it's a little less natural:
For example, one might think that a Comment Node is commenting on its Parent Node. Nope!
A Comment Node is merely a child of its Parent, and is likely commenting on the following (or preceding!) Sibling Node - not the Parent Node.
But there are some Nodes where it's not obvious how multiple Child Nodes of the same Type should be represented.
Take, for example, the Element Node. It allows - in fact needs - a Text Node as a Child Node to store the actual text of Leaf Elements.
One could say that in a typical XML document, all Element Nodes have:
either zero (for empty Elements), one, or multiple Child Element Nodes;
or exactly one Child Text Node.
But this isn't (apparently) stipulated in the standard - hence this post.
If a Child list has Child Text Nodes interspersed amongst Child Element Nodes, do they just get represented like that?
<Parent>
This is the first piece of text from the first Text Node.
<Child1>
...
</Child1>
<Child2>
...
</Child2>
This is the second piece of text from the second Text Node.
<Child3>
...
</Child3>
</Parent>
How does are multiple Child Text Nodes represented?
A simple concatenation of all the Texts? In the given order?
<Parent>
This is the first piece of text from the first Text Node. This is the second piece of text from the second Text Node.
</Parent>
How does one represent Child Text Nodes of Attr Nodes, as described/permitted in the above Node Types Table?
And I've not even considered EntityReference Nodes yet - which are also explicitly described as legal Child Nodes of Attr Nodes. (How?)
