"EntityReference" implementation (reference to parsed entity).
This is a non-core DOM class, supporting the "XML" feature.
It does not represent builtin entities (such as "&")
or character references, which are always directly expanded in
DOM trees.
Note that while the DOM specification permits these nodes to have
a readonly set of children, this is not required. Similarly, it does
not require a DOM to couple EntityReference nodes with any Entity nodes
that have the same entity name (and equivalent children). It also
effectively guarantees that references created directly or indirectly
through the Document.ImportNode method will not have children.
The level of functionality you may get is extremely variable.
Also significant is that even at their most functional level, the fact
that EntityReference children must be readonly has caused significant
problems when modifying work products held in DOM trees. Other problems
include issues related to undeclared namespace prefixes (and references
to the current default namespace) that may be found in the text of such
parsed entities nodes. These must be contextually bound as part of DOM
tree construction. When such nodes are moved, the namespace associated
with a given prefix (or default) may change to be in conflict with the
namespace bound to the node at creation time.
In short, avoid using this DOM functionality.
Constructs an EntityReference node associated with the specified
document. The creator should populate this with whatever contents
are appropriate, and then mark it as readonly.
This constructor should only be invoked by a Document as part of
its createEntityReference functionality, or through a subclass which
is similarly used in a "Sub-DOM" style layer.
"EntityReference" implementation (reference to parsed entity). This is a non-core DOM class, supporting the "XML" feature. It does not represent builtin entities (such as "&") or character references, which are always directly expanded in DOM trees.
Note that while the DOM specification permits these nodes to have a readonly set of children, this is not required. Similarly, it does not require a DOM to couple EntityReference nodes with any Entity nodes that have the same entity name (and equivalent children). It also effectively guarantees that references created directly or indirectly through the Document.ImportNode method will not have children. The level of functionality you may get is extremely variable.
Also significant is that even at their most functional level, the fact that EntityReference children must be readonly has caused significant problems when modifying work products held in DOM trees. Other problems include issues related to undeclared namespace prefixes (and references to the current default namespace) that may be found in the text of such parsed entities nodes. These must be contextually bound as part of DOM tree construction. When such nodes are moved, the namespace associated with a given prefix (or default) may change to be in conflict with the namespace bound to the node at creation time.
In short, avoid using this DOM functionality.