TheDOMImplementationinterface provides a number of methods for performing operations that are independent of any particular instance of the document object model.

DocumentFragmentis a "lightweight" or "minimal"Documentobject. It is very common to want to be able to extract a portion of a document's tree or to create a new fragment of a document. Imagine implementing a user command like cut or rearranging a document by moving fragments around. It is desirable to have an object which can hold such fragments and it is quite natural to use a Node for this purpose. While it is true that aDocumentobject could fulfill this role, aDocumentobject can potentially be a heavyweight object, depending on the underlying implementation. What is really needed for this is a very lightweight object.DocumentFragmentis such an object.

Furthermore, various operations -- such as inserting nodes as children of anotherNode-- may takeDocumentFragmentobjects as arguments; this results in all the child nodes of theDocumentFragmentbeing moved to the child list of this node.

The children of aDocumentFragmentnode are zero or more nodes representing the tops of any sub-trees defining the structure of the document.DocumentFragmentnodes do not need to bewell-formed XML documents(although they do need to follow the rules imposed upon well-formed XML parsed entities, which can have multiple top nodes). For example, aDocumentFragmentmight have only one child and that child node could be aTextnode. Such a structure model represents neither an HTML document nor a well-formed XML document.

When aDocumentFragmentis inserted into aDocument(or indeed any otherNodethat may take children) the children of theDocumentFragmentand not theDocumentFragmentitself are inserted into theNode. This makes theDocumentFragmentvery useful when the user wishes to create nodes that aresiblings; theDocumentFragmentacts as the parent of these nodes so that the user can use the standard methods from theNodeinterface, such asinsertBeforeandappendChild.

TheDocumentinterface represents the entire HTML or XML document. Conceptually, it is therootof the document tree, and provides the primary access to the document's data.

Since elements, text nodes, comments, processing instructions, etc. cannot exist outside the context of aDocument, theDocumentinterface also contains the factory methods needed to create these objects. TheNodeobjects created have aownerDocumentattribute which associates them with theDocumentwithin whose context they were created.

TheNodeinterface is the primary datatype for the entire Document Object Model. It represents a single node in the document tree. While all objects implementing theNodeinterface expose methods for dealing with children, not all objects implementing theNodeinterface may have children. For example,Textnodes may not have children, and adding children to such nodes results in aDOMExceptionbeing raised.

The attributesnodeName,nodeValueandattributesare included as a mechanism to get at node information without casting down to the specific derived interface. In cases where there is no obvious mapping of these attributes for a specificnodeType(e.g.,nodeValuefor anElementorattributesfor aComment), this returnsnull. Note that the specialized interfaces may contain additional and more convenient mechanisms to get and set the relevant information.

TheNodeListinterface provides the abstraction of an ordered collection of nodes, without defining or constraining how this collection is implemented.NodeListobjects in the DOM arelive.

The items in theNodeListare accessible via an integral index, starting from 0.

Objects implementing theNamedNodeMapinterface are used to represent collections of nodes that can be accessed by name. Note thatNamedNodeMapdoes not inherit fromNodeList;NamedNodeMapsare not maintained in any particular order. Objects contained in an object implementingNamedNodeMapmay also be accessed by an ordinal index, but this is simply to allow convenient enumeration of the contents of aNamedNodeMap, and does not imply that the DOM specifies an order to these Nodes.

NamedNodeMapobjects in the DOM arelive.

TheCharacterDatainterface extends Node with a set of attributes and methods for accessing character data in the DOM. For clarity this set is defined here rather than on each object that uses these attributes and methods. No DOM objects correspond directly toCharacterData, thoughTextand others do inherit the interface from it. Alloffsetsin this interface start from0.

As explained in theDOMStringinterface, text strings in the DOM are represented in UTF-16, i.e. as a sequence of 16-bit units. In the following, the term16-bit unitsis used whenever necessary to indicate that indexing on CharacterData is done in 16-bit units.

TheAttrinterface represents an attribute in anElementobject. Typically the allowable values for the attribute are defined in a document type definition.

Attrobjects inherit theNodeinterface, but since they are not actually child nodes of the element they describe, the DOM does not consider them part of the document tree. Thus, theNodeattributesparentNode,previousSibling, andnextSiblinghave anullvalue forAttrobjects. The DOM takes the view that attributes are properties of elements rather than having a separate identity from the elements they are associated with; this should make it more efficient to implement such features as default attributes associated with all elements of a given type. Furthermore,Attrnodes may not be immediate children of aDocumentFragment. However, they can be associated withElementnodes contained within aDocumentFragment. In short, users and implementors of the DOM need to be aware thatAttrnodes have some things in common with other objects inheriting theNodeinterface, but they also are quite distinct.

The attribute's effective value is determined as follows: if this attribute has been explicitly assigned any value, that value is the attribute's effective value; otherwise, if there is a declaration for this attribute, and that declaration includes a default value, then that default value is the attribute's effective value; otherwise, the attribute does not exist on this element in the structure model until it has been explicitly added. Note that thenodeValueattribute on theAttrinstance can also be used to retrieve the string version of the attribute's value(s).

In XML, where the value of an attribute can contain entity references, the child nodes of theAttrnode may be eitherTextorEntityReferencenodes (when these are in use; see the description ofEntityReferencefor discussion). Because the DOM Core is not aware of attribute types, it treats all attribute values as simple strings, even if the DTD or schema declares them as havingtokenizedtypes.

TheElementinterface represents anelementin an HTML or XML document. Elements may have attributes associated with them; since theElementinterface inherits fromNode, the genericNodeinterface attributeattributesmay be used to retrieve the set of all attributes for an element. There are methods on theElementinterface to retrieve either anAttrobject by name or an attribute value by name. In XML, where an attribute value may contain entity references, anAttrobject should be retrieved to examine the possibly fairly complex sub-tree representing the attribute value. On the other hand, in HTML, where all attributes have simple string values, methods to directly access an attribute value can safely be used as aconvenience.

TheTextinterface inherits fromCharacterDataand represents the textual content (termedin XML) of anElementorAttr. If there is no markup inside an element's content, the text is contained in a single object implementing theTextinterface that is the only child of the element. If there is markup, it is parsed into theinformation items(elements, comments, etc.) andTextnodes that form the list of children of the element.

When a document is first made available via the DOM, there is only oneTextnode for each block of text. Users may create adjacentTextnodes that represent the contents of a given element without any intervening markup, but should be aware that there is no way to represent the separations between these nodes in XML or HTML, so they will not (in general) persist between DOM editing sessions. Thenormalize()method onNodemerges any such adjacentTextobjects into a single node for each block of text.

This interface inherits fromCharacterDataand represents the content of a comment, i.e., all the characters between the starting '<!--' and ending '-->'. Note that this is the definition of a comment in XML, and, in practice, HTML, although some HTML tools may implement the full SGML comment structure.

CDATA sections are used to escape blocks of text containing characters that would otherwise be regarded as markup. The only delimiter that is recognized in a CDATA section is the "]]>" string that ends the CDATA section. CDATA sections cannot be nested. Their primary purpose is for including material such as XML fragments, without needing to escape all the delimiters.

TheDOMStringattribute of theTextnode holds the text that is contained by the CDATA section. Note that thismaycontain characters that need to be escaped outside of CDATA sections and that, depending on the character encoding ("charset") chosen for serialization, it may be impossible to write out some characters as part of a CDATA section.

TheCDATASectioninterface inherits from theCharacterDatainterface through theTextinterface. AdjacentCDATASectionnodes are not merged by use of thenormalizemethod of theNodeinterface.

EachDocumenthas adoctypeattribute whose value is eithernullor aDocumentTypeobject. TheDocumentTypeinterface in the DOM Core provides an interface to the list of entities that are defined for the document, and little else because the effect of namespaces and the various XML schema efforts on DTD representation are not clearly understood as of this writing.

The DOM Level 2 doesn't support editingDocumentTypenodes.

This interface represents a notation declared in the DTD. A notation either declares, by name, the format of an unparsed entity (seeof the XML 1.0 specification), or is used for formal declaration of processing instruction targets (seeof the XML 1.0 specification). ThenodeNameattribute inherited fromNodeis set to the declared name of the notation.

The DOM Level 1 does not support editingNotationnodes; they are thereforereadonly.

ANotationnode does not have any parent.

This interface represents an entity, either parsed or unparsed, in an XML document. Note that this models the entity itselfnotthe entity declaration.Entitydeclaration modeling has been left for a later Level of the DOM specification.

ThenodeNameattribute that is inherited fromNodecontains the name of the entity.

An XML processor may choose to completely expand entities before the structure model is passed to the DOM; in this case there will be noEntityReferencenodes in the document tree.

XML does not mandate that a non-validating XML processor read and process entity declarations made in the external subset or declared in external parameter entities. This means that parsed entities declared in the external subset need not be expanded by some classes of applications, and that the replacement value of the entity may not be available. When the replacement value is available, the correspondingEntitynode's child list represents the structure of that replacement text. Otherwise, the child list is empty.

The DOM Level 2 does not support editingEntitynodes; if a user wants to make changes to the contents of anEntity, every relatedEntityReferencenode has to be replaced in the structure model by a clone of theEntity's contents, and then the desired changes must be made to each of those clones instead.Entitynodes and all theirdescendantsarereadonly.

AnEntitynode does not have any parent.

EntityReferenceobjects may be inserted into the structure model when an entity reference is in the source document, or when the user wishes to insert an entity reference. Note that character references and references to predefined entities are considered to be expanded by the HTML or XML processor so that characters are represented by their Unicode equivalent rather than by an entity reference. Moreover, the XML processor may completely expand references to entities while building the structure model, instead of providingEntityReferenceobjects. If it does provide such objects, then for a givenEntityReferencenode, it may be that there is noEntitynode representing the referenced entity. If such anEntityexists, then the subtree of theEntityReferencenode is in general a copy of theEntitynode subtree. However, this may not be true when an entity contains an unboundnamespace prefix. In such a case, because the namespace prefix resolution depends on where the entity reference is, thedescendantsof theEntityReferencenode may be bound to differentnamespace URIs.

As forEntitynodes,EntityReferencenodes and all theirdescendantsarereadonly.

TheProcessingInstructioninterface represents a "processing instruction", used in XML as a way to keep processor-specific information in the text of the document.

Extensions to a language's native String class or interface