Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Difference between Node and Element? 1
- Thread starter jsteph
- Start date
An element would more properly be called an element node, to distinguish it from other types of nodes:[ul]
[li]the root node[/li]
[li]attribute nodes[/li]
[li]text nodes[/li]
[li]comment nodes[/li]
[li]processing instruction nodes[/li]
[li]namespace nodes[/li][/ul]
I may be missing a node type.
Does this clarify things?
Tom Morrison
[li]the root node[/li]
[li]attribute nodes[/li]
[li]text nodes[/li]
[li]comment nodes[/li]
[li]processing instruction nodes[/li]
[li]namespace nodes[/li][/ul]
I may be missing a node type.
Does this clarify things?
Tom Morrison
- Thread starter
- #3
Sort of. I had the understanding that any node could contain text, so how is a 'text node' different?
For example:
In this example, is <name> an element or text node? Also, at the simplest level, is this how one would store the name? Or would one use an attribute of the <name> thing to store the actual name and put nothing in-between the start and end tags?
Thanks,
--Jim
For example:
Code:
<root>
<customer>
<name>
Acme Anvil Co.
</name>
<address>
123 elm
</address>
</customer>
</root>Thanks,
--Jim
Jim,
An element node can have subordinate text nodes, element nodes, arribute nodes and namespace nodes (and comment nodes, I guess, not exactly sure how those are represented in the DOM). The text node subordinate to the name element would be
note that whitespace would be included.
I should probably stop before I make too much a fool of myself. I am more involved in XSLT, which has a somewhat different taxonomy.
Tom Morrison
An element node can have subordinate text nodes, element nodes, arribute nodes and namespace nodes (and comment nodes, I guess, not exactly sure how those are represented in the DOM). The text node subordinate to the name element would be
Code:
Acme Anvil Co.I should probably stop before I make too much a fool of myself. I am more involved in XSLT, which has a somewhat different taxonomy.
Tom Morrison
-
1
- #5
>I had the understanding that any node could contain text, so how is a 'text node' different?
A "text node" in the technical sense will be characterised by its type attribute (3). The salient feature of it is that it can only be a leaf of the document tree. It is incapable of having other nodes as its children.
>In this example, is <name> an element or text node?
<name> is an "element node". It's node type attribute returns 1.
>Also, at the simplest level, is this how one would store the name? Or would one use an attribute of the <name> thing to store the actual name and put nothing in-between the start and end tags?
It is equally viable and one should not let one preference dictate over the other.
For "data-oriented" store and as simple (atomic) a data as a name---whatever it means---use an attribute would have some minute gain in processing time which might add up. But for some structured data, the data would need a element tree of its own to make a sense out of it which is better suit to reflect a hierarchical relation. Using attributes would mean a flat structure less apt to reflect the hierachical relation among them. A flat attribute collection might soon be getting out of control if more sophisticated info needed to be added as attribute nodes like text nodes are leaves incapable of containing other nodes. There really is no definite answer to the question. So, at the simplest (atomic) level, it is the use of attribute for "data-oriented" store. But, it is less readable and readability very often is an important factor to make the choice. I wouldn't be surprise attribute will not be preferred in this case for a data semantically of such a need to being standing-out as the name of a person say.
However, priority would be quite different for "content-management-oriented" store where a lot of mixed type elements would be present. There the contents most probably need to be stored in the text nodes and attributes be relegated to marginal or stylistic info intermixed within stylistic or semantic elements.
There are also many factors influencing the management decision, like readability and ease of maintenance.
I make no pretention on each and every of the above matters.
A "text node" in the technical sense will be characterised by its type attribute (3). The salient feature of it is that it can only be a leaf of the document tree. It is incapable of having other nodes as its children.
>In this example, is <name> an element or text node?
<name> is an "element node". It's node type attribute returns 1.
>Also, at the simplest level, is this how one would store the name? Or would one use an attribute of the <name> thing to store the actual name and put nothing in-between the start and end tags?
It is equally viable and one should not let one preference dictate over the other.
For "data-oriented" store and as simple (atomic) a data as a name---whatever it means---use an attribute would have some minute gain in processing time which might add up. But for some structured data, the data would need a element tree of its own to make a sense out of it which is better suit to reflect a hierarchical relation. Using attributes would mean a flat structure less apt to reflect the hierachical relation among them. A flat attribute collection might soon be getting out of control if more sophisticated info needed to be added as attribute nodes like text nodes are leaves incapable of containing other nodes. There really is no definite answer to the question. So, at the simplest (atomic) level, it is the use of attribute for "data-oriented" store. But, it is less readable and readability very often is an important factor to make the choice. I wouldn't be surprise attribute will not be preferred in this case for a data semantically of such a need to being standing-out as the name of a person say.
However, priority would be quite different for "content-management-oriented" store where a lot of mixed type elements would be present. There the contents most probably need to be stored in the text nodes and attributes be relegated to marginal or stylistic info intermixed within stylistic or semantic elements.
There are also many factors influencing the management decision, like readability and ease of maintenance.
I make no pretention on each and every of the above matters.
- Thread starter
- #6
- Status
Similar threads
- Locked
- Question