Namespace Telerik.WinForms.Documents.FormatProviders.Html.Parsing.Dom

Classes

DOM operations only raise exceptions in "exceptional" circumstances, i.e., when an operation is impossible to perform (either for logical reasons, because data is lost, or because the implementation has become unstable). In general, DOM methods return specific error values in ordinary processing situations, such as out-of-bound errors when using

NodeList

Implementations should raise other exceptions under other circumstances. For example, implementations should raise an implementation-dependent exception if a

null

argument is passed.

Some languages and object systems do not support the concept of exceptions. For such systems, error conditions may be indicated using native error reporting mechanisms. For some bindings, for example, methods may return error codes similar to those listed in the corresponding method descriptions.

Interfaces

IAttr

The

Attr

interface represents an attribute in an

Element

object. Typically the allowable values for the

attribute are defined in a document type definition.

Attr

objects inherit the

Node

interface, 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, the

Node

attributes

parentNode

previousSibling

, and

nextSibling

have a

null

value for

Attr

objects. 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,

Attr

nodes may not be immediate children of a

DocumentFragment

. However, they can be associated with

Element

nodes contained within a

DocumentFragment

. In short, users and implementors of the

DOM need to be aware that

Attr

nodes have some things in common with other objects inheriting the

Node

interface, 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 the

nodeValue

attribute on the

Attr

instance 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 the

Attr

node may be either

Text

EntityReference

nodes (when these are

in use; see the description of

EntityReference

for 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 having tokenized types.

ICdataSection

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.

The

DOMString

attribute of the

Text

node holds the text that is contained by the CDATA section. Note that this may contain 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.

The

CDATASection

interface inherits from the

CharacterData

interface through the

Text

interface. Adjacent

CDATASection

nodes are not merged by use of the

normalize

method of the

Node

interface. Because no markup is recognized within a

CDATASection

, character numeric references cannot be used as an escape mechanism when serializing. Therefore, action needs to be taken when serializing a

CDATASection

with a character encoding where some of the

contained characters cannot be represented. Failure to do so would not produce well-formed XML.One potential solution in the serialization process is to end the CDATA section before the character, output the character using a character reference or entity reference, and open a new CDATA section for any further characters in the text node. Note, however, that some code conversion libraries at the time of writing do not return an error or exception when a character is missing from the encoding, making the task of ensuring that data is not corrupted on serialization more difficult.

ICharacterData

The

CharacterData

interface 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 to

CharacterData

, though

Text

and others do

inherit the interface from it. All

offsets

in this interface start from

As explained in the

DOMString

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

IComment

This interface inherits from

CharacterData

and 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.

IDocument

The

Document

interface represents the entire HTML or XML document. Conceptually, it is the root of 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 a

Document

, the

Document

interface also contains the factory methods needed

to create these objects. The

Node

objects created have a

ownerDocument

attribute which associates them with the

Document

within whose context they were created.

IDocumentFragment

DocumentFragment

is a "lightweight" or "minimal"

Document

object. 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 a

Document

object could fulfill this role, a

Document

object can potentially be a heavyweight object, depending on the underlying implementation. What is really needed for this is a very lightweight object.

DocumentFragment

is such an object.

Furthermore, various operations -- such as inserting nodes as children of another

Node

-- may take

DocumentFragment

objects as arguments; this results in all the child nodes of the

DocumentFragment

being moved to the child list of this node.

The children of a

DocumentFragment

node are zero or more nodes representing the tops of any sub-trees defining the structure of the document.

DocumentFragment

nodes do not need to be well-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, a

DocumentFragment

might have only one child and that child node could be a

Text

node. Such a structure model represents neither an HTML document nor a well-formed XML document.

When a

DocumentFragment

is inserted into a

Document

(or indeed any other

Node

that may take children) the children of the

DocumentFragment

and not the

DocumentFragment

itself are inserted into the

Node

. This makes the

DocumentFragment

very useful when the user wishes to create nodes that are siblings; the

DocumentFragment

acts as the parent of these nodes so that the user can use the standard methods from the

Node

interface, such as

insertBefore

and

appendChild

IDocumentType

Each

Document

has a

doctype

attribute whose value is either

null

or a

DocumentType

object. The

DocumentType

interface 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 editing

DocumentType

nodes.

IDomImplementation

The

DOMImplementation

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

IElement

The

Element

interface represents an element in an HTML or XML document. Elements may have attributes associated with them; since the

Element

interface inherits from

Node

, the

generic

Node

interface attribute

attributes

may be used to retrieve the set of all attributes for an element. There are methods on the

Element

interface to retrieve either an

Attr

object by name or an attribute value by name. In XML,

where an attribute value may contain entity references, an

Attr

object 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 a convenience.In DOM Level 2, the method

normalize

is inherited from the

Node

interface where it was moved.

IEntityReference

EntityReference

objects 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 providing <pre><code>EntityReference</code></pre> 
       objects. If it does provide such objects, then for a given

EntityReference

node, it may be that there is no

Entity

node representing the referenced entity. If such an

Entity

exists, then the subtree of the

EntityReference

node is in general a copy of the

Entity

node subtree. However, this may not be true when an

entity contains an unbound namespace prefix. In such a case, because the namespace prefix resolution depends on where the entity reference is, the descendants of the

EntityReference

node may be bound to different namespace URIs.

As for

Entity

nodes,

EntityReference

nodes and all their descendants are readonly.

INamedNodeMap

Objects implementing the

NamedNodeMap

interface are used to represent collections of nodes that can be accessed by name. Note that

NamedNodeMap

does not inherit from

NodeList

;

NamedNodeMaps

are not maintained in any particular order.

Objects contained in an object implementing

NamedNodeMap

may also be accessed by an ordinal index, but this is simply to allow convenient enumeration of the contents of a

NamedNodeMap

, and does not imply that the DOM specifies an order to these Nodes.

NamedNodeMap

objects in the DOM are live.

INode

The

Node

interface is the primary datatype for the entire Document Object Model. It represents a single node in the document tree. While all objects implementing the

Node

interface expose methods for dealing with children, not all objects implementing the

Node

interface may have children. For example,

Text

nodes may not have children, and adding children to

such nodes results in a

DOMException

being raised.

The attributes

nodeName

nodeValue

and

attributes

are 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 specific

nodeType

(e.g.,

nodeValue

for an

Element

attributes

for a

Comment

), this returns

null

. Note that the specialized interfaces may contain additional and more convenient mechanisms to get and set the relevant information.

INodeList

The

NodeList

interface provides the abstraction of an ordered collection of nodes, without defining or constraining how this collection is implemented.

NodeList

objects in the DOM are live.

The items in the

NodeList

are accessible via an integral index, starting from 0.

IProcessingInstruction

The

ProcessingInstruction

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

IText

The

Text

interface inherits from

CharacterData

and represents the textual content (termed character data in XML) of an

Element

Attr

. If there is no markup inside

an element's content, the text is contained in a single object implementing the

Text

interface that is the only child of the element. If there is markup, it is parsed into the information items (elements, comments, etc.) and

Text

nodes that form the list of children of the element.

When a document is first made available via the DOM, there is only one

Text

node for each block of text. Users may create adjacent

Text

nodes 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. The

normalize()

method on

Node

merges any such

adjacent

Text

objects into a single node for each block of text.

Enums

NodeType

Namespace Telerik.WinForms.Documents.FormatProviders.Html.Parsing.Dom

Classes

Interfaces

Enums

Getting Started

Support Resources

Community

Product Bundles

DevCraft

Web

Mobile

Document Management

Desktop

Reporting

Testing & Mocking

CMS

UI/UX Tools

Debugging

Free Tools

Support and Learning

Productivity and Design Tools

Namespace Telerik.WinForms.Documents.FormatProviders.Html.Parsing.Dom

Classes

Interfaces

Enums

Getting Started

Support Resources

Community