NodeImpl provides the basic structure of a DOM tree. It is never used directly, but instead is subclassed to add type and data information, and additional methods, appropriate to each node of the tree. Only its subclasses should be instantiated -- and those, with the exception of Document itself, only through a specific Document's factory methods.
The Node interface provides shared behaviors such as siblings and children, both for consistancy and so that the most common tree operations may be performed without constantly having to downcast to specific node types. When there is no obvious mapping for one of these queries, it will respond with null. Note that the default behavior is that children are forbidden. To permit them, the subclass ParentNode overrides several methods.
NodeImpl also implements NodeList, so it can return itself in response to the getChildNodes() query. This eliminiates the need for a separate ChildNodeList object. Note that this is an IMPLEMENTATION DETAIL; applications should _never_ assume that this identity exists.
All nodes in a single document must originate in that document. (Note that this is much tighter than "must be same implementation") Nodes are all aware of their ownerDocument, and attempts to mismatch will throw WRONG_DOCUMENT_ERR.
However, to save memory not all nodes always have a direct reference to their ownerDocument. When a node is owned by another node it relies on its owner to store its ownerDocument. Parent nodes always store it though, so there is never more than one level of indirection. And when a node doesn't have an owner, ownerNode refers to its ownerDocument.
This class doesn't directly support mutation events, however, it still implements the EventTarget interface and forward all related calls to the document so that the document class do so.
@author Arnaud Le Hors, IBM
@author Joe Kesselman, IBM
@version $Id: NodeImpl.java,v 1.58 2002/10/01 19:59:39 lmartin Exp $
@since PR-DOM-Level-1-19980818.