xdocs/dom/xml/core/introduction.xml - xerces-j - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!-- $Id: introduction.xml 225913 2001-06-01 11:15:37Z dims $ -->
 <!--
  *************************************************************************
  * BEGINNING OF DOM INTRODUCTION                                         *
  *************************************************************************
 -->
 <div1 id="Introduction">
   <head>What is the Document Object Model?</head>

   <orglist role="editors">
     <member>
       <name>Philippe Le H&eacute;garet</name>
       <affiliation>W3C</affiliation>
     </member>
     <member>
       <name>Lauren Wood</name>
       <affiliation>SoftQuad Software Inc., WG Chair</affiliation>
     </member>
     <member>
       <name>Jonathan Robie</name>
       <affiliation>Texcel (for DOM Level 1)</affiliation>
     </member>
   </orglist>

   <div2 id="ID-E7C3082">
     <head>Introduction</head>
     <p>The Document Object Model (DOM) is an application programming interface
       (<termref def="dt-API">API</termref>) for valid <termref def="dt-HTML">HTML</termref> and
       well-formed <termref def="dt-XML">XML</termref> documents. It defines the logical structure of documents and
       the way a document is accessed and manipulated. In the DOM specification,
       the term "document" is used in the broad sense - increasingly, XML is being used as a
       way of representing many different kinds of information that may
       be stored in diverse systems, and much of this would traditionally
       be seen as data rather than as documents. Nevertheless, XML presents
       this data as documents, and the DOM may be used to manage this data.</p>

     <p>With the Document
       Object Model, programmers can build documents, navigate
       their structure, and add, modify, or delete elements and content.
       Anything found in an HTML or XML document can be accessed,
       changed, deleted, or added using the Document Object Model,
       with a few exceptions - in particular, the DOM <termref
       def="dt-interface">interfaces</termref> for
       the XML internal and external subsets have not yet been specified.</p>
     <p>As a W3C specification, one important objective for the Document
       Object Model is to provide a standard programming interface that
       can be used in a wide variety of environments and <termref
       def="dt-application">applications</termref>.
       The DOM is designed to be used with any programming
       language. In order to provide a precise, language-independent
       specification of the DOM interfaces, we have chosen to define
       the specifications in Object Management Group (OMG) IDL <bibref
       ref="OMGIDL"/>, as defined in the CORBA 2.3.1 specification <bibref
       ref="CORBA"/>. In addition to the OMG IDL specification, we provide
       <termref def="dt-lang-binding">language bindings</termref> for Java <bibref ref="Java"/> and ECMAScript <bibref
       ref="ECMAScript"/> (an industry-standard scripting
       language based on JavaScript <bibref ref="JavaScript"/> and JScript
       <bibref ref='JScript'/>).</p>
     <note><p>OMG IDL is used only as a language-independent and
 	implementation-neutral way to specify <termref def="dt-interface">interfaces</termref>. Various other
 	IDLs could have been used (<bibref ref="COM"/>, <bibref
         ref="JavaIDL"/>, <bibref ref="MSIDL"/>, ...). In general, IDLs
 	are designed for specific computing environments. The Document Object
 	Model can be implemented in any computing environment, and does not
 	require the object binding runtimes generally associated with
 	such IDLs.
       </p></note>

   </div2>
   <div2 id="ID-E7C30821">
     <head>What the Document Object Model is</head>
     <p>The DOM is a programming <termref def="dt-API">API</termref> for documents.
       It is based on an object structure that closely resembles the structure of the
       documents it <termref def="dt-model">models</termref>. For instance, consider this table, taken
       from an HTML document: </p>
     <eg role="code">
       &lt;TABLE&gt;
       &lt;TBODY&gt;
       &lt;TR&gt;
       &lt;TD&gt;Shady Grove&lt;/TD&gt;
       &lt;TD&gt;Aeolian&lt;/TD&gt;
       &lt;/TR&gt;
       &lt;TR&gt;
       &lt;TD&gt;Over the River, Charlie&lt;/TD&gt;
       &lt;TD&gt;Dorian&lt;/TD&gt;
       &lt;/TR&gt;
       &lt;/TBODY&gt;
       &lt;/TABLE&gt;
     </eg>
     <p>A graphical representation of the DOM of the example table is:
       <graphic source="./images/table.gif" alt="graphical representation of the
 	       DOM of the example table"/>
     </p>
     <p>In the DOM, documents have a logical
       structure which is very much like a tree; to be more precise, which is
       like a &quot;forest&quot; or &quot;grove&quot;,
       which can contain more than one tree. Each document contains zero or one
       doctype nodes, one root element node, and zero or more comments
 		or processing instructions; the root element serves as the root
 		of the element tree for the document. However, the DOM
       does not specify that documents must be <emph>implemented</emph> as a
       tree or a grove<!--but not the same as an sgml grove-->, nor
       does it specify how the relationships among objects be
       implemented. The DOM is a logical model that may be implemented in any
       convenient manner. In this
       specification, we use the term <emph>structure model</emph> to
       describe the tree-like representation of a document.
       We also use the term "tree" when referring to the arrangement of
       those information items which can be reached by using "tree-walking"
       methods; (this does not include attributes).
       One important property of DOM structure models
       is <emph>structural isomorphism</emph>: if any two Document
       Object Model implementations are used to create a representation
       of the same document, they will create the same structure model,
       in accordance with the XML Information Set <bibref ref="InfoSet"/>.</p>
     <note><p>There may be some variations depending on the parser being
 	used to build the DOM. For instance, the DOM may not contain
 	whitespaces in element content if the parser discards them.</p>
     </note>
       <p>The name &quot;Document Object Model&quot; was chosen because
       it is an &quot;<termref def="dt-object-model">object model</termref>&quot; in the traditional
       object oriented design sense: documents are modeled using
       objects, and the model encompasses not only the structure of a
       document, but also the behavior of a document and the objects
       of which it is composed. In other words, the nodes in the
       above diagram do not represent a data structure, they
       represent objects, which have functions and identity. As an
       object model, the DOM identifies:</p>
     <ulist>
       <item><p>the interfaces and objects used to represent and manipulate
 	  a document</p></item>
       <item><p>the semantics of these interfaces and objects - including
 	  both behavior and attributes</p></item>
       <item><p>the relationships and collaborations among these interfaces
 	  and objects</p></item>
     </ulist>

     <p>The structure of SGML documents has traditionally been
       represented by an abstract <termref def="dt-datamodel">data model</termref>, not by an object model.
       In an abstract <termref def="dt-datamodel">data model</termref>, the model is centered around the
       data. In object oriented programming languages, the data itself
       is encapsulated in objects that hide the data, protecting it
       from direct external manipulation. The functions associated with
       these objects determine how the objects may be manipulated, and
       they are part of the object model.</p>

   </div2>
   <div2 id="ID-E7C30822">
     <head>What the Document Object Model is not</head>
     <p>This section is designed to give a more precise understanding
       of the DOM by distinguishing it from other
       systems that may seem to be like it.</p>
     <ulist>
       <item><p>The Document Object Model is not a binary specification.
 	  DOM programs written in the same language binding will be
 	  source code compatible across platforms, but the DOM
 	  does not define any form of binary interoperability.</p></item>
       <item><p>The Document Object Model is not a way of persisting objects
 	  to XML or HTML. Instead of specifying how objects may be
 	  represented in XML, the DOM specifies how
 	  XML and HTML documents are represented as objects, so that
 	  they may be used in object oriented programs.</p></item>
       <item><p>The Document Object Model is not a set of data structures;
 	  it is an <termref def="dt-object-model">object model</termref> that specifies interfaces. Although this
 	  document contains diagrams showing parent/child relationships,
 	  these are logical relationships defined by the programming
 	  interfaces, not representations of any particular internal
 	  data structures.</p></item>
       <item><p>The Document Object Model does not define what information in a
 	  document is relevant or how information in a document is
 	  structured. For XML, this is specified by the W3C XML Information Set
 	  <bibref ref="InfoSet"/>. The DOM is simply an <termref def="dt-API">API</termref> to this information
 	  set.</p></item>
       <item><p>The Document Object Model, despite its name, is not a
 	  competitor to the Component Object Model (COM). COM, like
 	  CORBA, is a language independent way to specify interfaces and
 	  objects; the DOM is a set of interfaces and
 	  objects designed for managing HTML and XML documents. The DOM
 	  may be implemented using language-independent systems like COM
 	  or CORBA; it may also be implemented using language-specific
 	  bindings like the Java or ECMAScript bindings specified in
 	  this document.</p></item>
     </ulist>
   </div2>
   <div2 id="ID-E7C30823">
     <head>Where the Document Object Model came from</head>
     <p>The DOM originated as a specification to
       allow JavaScript scripts and Java programs to be portable among
       Web browsers.  "Dynamic HTML" was  the immediate ancestor of the
       Document Object Model, and it was originally thought of largely
       in terms of  browsers. However, when the DOM
       Working Group was formed at W3C, it was also joined by vendors in other
       domains, including HTML or XML editors and document
       repositories. Several of these vendors had worked with SGML
       before XML was developed; as a result, the DOM
       has been influenced by SGML Groves and the HyTime standard. Some
       of these vendors had also developed their own object models for
       documents in order to provide an API for SGML/XML
       editors or document repositories, and these object models have
       also influenced the DOM.</p>
   </div2>


   <div2 id="ID-E7C30824"><head>Entities and the DOM Core</head>
     <p>In the fundamental DOM interfaces, there are no objects representing
       entities. Numeric character references, and references to the
       pre-defined entities in HTML and XML, are replaced by the
       single character that makes up the entity's replacement.
       For example, in:
     </p>
       <eg role="code">
         &lt;p&gt;This is a dog &amp;amp; a cat&lt;/p&gt;
       </eg>
     <p>
       the "&amp;amp;" will be replaced by the character "&amp;", and the text
       in the P element will form a single continuous sequence of
       characters. Since numeric character references and pre-defined entities
       are not recognized as such in CDATA sections, or in the SCRIPT and STYLE
       elements in HTML, they are not replaced by the single character they
       appear to refer to. If the example above were enclosed in a CDATA
       section, the "&amp;amp;" would not be replaced by "&amp;"; neither would
       the &lt;p&gt; be recognized as a start tag. The representation of general
       entities, both internal and external, are defined within the
       extended (XML) interfaces of DOM Level 1 <bibref ref='DOM-Level-1'/>.</p>
     <p>
       Note: When a DOM representation of a document is serialized
       as XML or HTML text, applications will need to check each
       character in text data to see if it needs to be escaped
       using a numeric or pre-defined entity. Failing to do so
       could result in invalid HTML or XML. Also, <termref
       def="dt-implementation">implementations</termref> should be
       aware of the fact that serialization into a character encoding
       ("charset") that does not fully cover ISO 10646 may fail if there are
       characters in markup or CDATA sections that are not present in the
       encoding.</p>
   </div2>

   <div2 id="ID-Conformance">
     <head>Conformance</head>
     <p>
       This section explains the different levels of conformance to DOM Level 2.
       DOM Level 2 consists of 14 modules. It is possible to conform to DOM
       Level 2, or to a DOM Level 2 module.
     </p>

     <p>
       An implementation is DOM Level 2 conformant if it supports the Core
       module defined in this document (see <specref ref="ID-BBACDC08"/>). An
       implementation conforms to a DOM Level 2 module if it supports all the
       interfaces for that module and the associated semantics.
     </p>
     <p>
       Here is the complete list of DOM Level 2.0 modules and the features used
       by them.  Feature names are case-insensitive.
     </p>

     <glist>
       <gitem>
 	<label>Core module</label>
 	<def>
 	  <p>
 	    defines the feature <xspecref
 	    href="core.html#ID-BBACDC08">"Core"</xspecref>.
 	  </p>
 	</def>
       </gitem>
       <gitem>
 	<label>XML module</label>
 	<def>
 	  <p>
 	    defines the feature <xspecref
 	    href="core.html#ID-E067D597">"XML"</xspecref>.
 	  </p>
 	</def>
       </gitem>
       <gitem>
 	<label>HTML module</label>
 	<def>
 	  <p>defines the feature "HTML". (see <bibref ref="DOMHTML-inf"/>).</p>
 	  <note>
 	    <p>At time of publication, this DOM Level 2 module is not yet a W3C Recommendation.</p>
 	  </note>
 	</def>
       </gitem>
       <gitem>
 	<label>Views module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&views.latest.url;/views.html'>"Views"</xspecref> in <bibref ref="DOMViews-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Style Sheets module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&style.latest.url;/stylesheets.html'>"StyleSheets"</xspecref>  in <bibref ref="DOMStyleSheets-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>CSS module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&style.latest.url;/css.html'>"CSS"</xspecref>  in <bibref ref="DOMCSS-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>CSS2 module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&style.latest.url;/css.html'>"CSS2"</xspecref>  in <bibref ref="DOMCSS-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Events module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&events.latest.url;/events.html'>"Events"</xspecref>  in <bibref ref="DOMEvents-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>User interface Events module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&events.latest.url;/events.html'>"UIEvents"</xspecref>  in <bibref ref="DOMEvents-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Mouse Events module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&events.latest.url;/events.html'>"MouseEvents"</xspecref>  in <bibref ref="DOMEvents-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Mutation Events module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&events.latest.url;/events.html'>"MutationEvents"</xspecref>  in <bibref ref="DOMEvents-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>HTML Events module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&events.latest.url;/events.html'>"HTMLEvents"</xspecref>  in <bibref ref="DOMEvents-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Range module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&traversal-range.latest.url;/ranges.html'>"Range"</xspecref>  in <bibref ref="DOMRange-inf"/>.</p>
 	</def>
       </gitem>
       <gitem>
 	<label>Traversal module</label>
 	<def>
 	  <p>defines the feature <xspecref
 					   href='&traversal-range.latest.url;/traversal.html'>"Traversal"</xspecref>  in <bibref ref="DOMTraversal-inf"/>.</p>
 	</def>
       </gitem>
     </glist>

     <p>
       A DOM implementation must not return <code>"true"</code> to the
       <code>hasFeature(feature, version)</code> <termref
       def="dt-method">method</termref> of the <code>DOMImplementation</code>
       interface for that feature unless the implementation conforms to that
       module. The <code>version</code> number for all features used in DOM
       Level 2.0 is "2.0".
     </p>

   </div2>

   <div2 id="ID-E7C30826"><head>DOM Interfaces and DOM Implementations</head>

     <p>The DOM specifies interfaces which may be used to manage XML or
       HTML documents. It is important to realize that these interfaces
       are an abstraction - much like "abstract base classes" in C++,
       they are a means of specifying a way to access and manipulate an
       application's internal representation of a document. Interfaces
 	do not imply a particular concrete
       implementation. Each DOM application is free to maintain
       documents in any convenient representation, as long as the
       interfaces shown in this specification are supported. Some
       DOM implementations will be existing programs that use the
       DOM interfaces to access software written long before the
       DOM specification existed. Therefore, the DOM is designed
       to avoid implementation dependencies; in particular,</p>
     <olist>
       <item><p>Attributes defined in the IDL do not imply concrete
 	  objects which must have specific data members - in the
 	  language bindings, they are translated to a pair of
 	  get()/set() functions, not to a data member. Read-only
 	  attributes have only a get() function in the language
 	  bindings.  </p>
       </item>
       <item><p>DOM applications may provide additional interfaces
 	  and objects not found in this specification and still be
 	  considered DOM conformant.</p></item>
       <item><p>Because we specify interfaces and not the actual
 	  objects that are to be created, the DOM cannot know what
 	  constructors to call for an implementation.  In general,
 	  DOM users call the createX() methods on the Document
 	  class to create document structures, and DOM
 	  implementations create their own internal representations
 	  of these structures in their implementations of the
 	  createX() functions.
 	</p></item>
     </olist>
     <p>
       The Level 1 interfaces were extended to provide both Level 1 and Level 2
       functionality.
     </p>
     <p>
       DOM implementations in languages other than Java or ECMAScript may
       choose bindings that are appropriate and natural for their language and
       run time environment.  For example, some systems may need to create a
       Document2 class which inherits from Document and contains the new methods
       and attributes.
     </p>
     <p>DOM Level 2 does not specify multithreading mechanisms.</p>
   </div2>
 </div1>
 <!--
   *************************************************************************
   * END OF DOM INTRODUCTION                                               *
   *************************************************************************
 -->
	<?xml version="1.0" encoding="UTF-8"?>
	<!-- $Id: introduction.xml 225913 2001-06-01 11:15:37Z dims $ -->
	<!--
	*************************************************************************
	* BEGINNING OF DOM INTRODUCTION *
	*************************************************************************
	-->
	<div1 id="Introduction">
	<head>What is the Document Object Model?</head>

	<orglist role="editors">
	<member>
	<name>Philippe Le Hégaret</name>
	<affiliation>W3C</affiliation>
	</member>
	<member>
	<name>Lauren Wood</name>
	<affiliation>SoftQuad Software Inc., WG Chair</affiliation>
	</member>
	<member>
	<name>Jonathan Robie</name>
	<affiliation>Texcel (for DOM Level 1)</affiliation>
	</member>
	</orglist>

	<div2 id="ID-E7C3082">
	<head>Introduction</head>
	<p>The Document Object Model (DOM) is an application programming interface
	(<termref def="dt-API">API</termref>) for valid <termref def="dt-HTML">HTML</termref> and
	well-formed <termref def="dt-XML">XML</termref> documents. It defines the logical structure of documents and
	the way a document is accessed and manipulated. In the DOM specification,
	the term "document" is used in the broad sense - increasingly, XML is being used as a
	way of representing many different kinds of information that may
	be stored in diverse systems, and much of this would traditionally
	be seen as data rather than as documents. Nevertheless, XML presents
	this data as documents, and the DOM may be used to manage this data.</p>

	<p>With the Document
	Object Model, programmers can build documents, navigate
	their structure, and add, modify, or delete elements and content.
	Anything found in an HTML or XML document can be accessed,
	changed, deleted, or added using the Document Object Model,
	with a few exceptions - in particular, the DOM <termref
	def="dt-interface">interfaces</termref> for
	the XML internal and external subsets have not yet been specified.</p>
	<p>As a W3C specification, one important objective for the Document
	Object Model is to provide a standard programming interface that
	can be used in a wide variety of environments and <termref
	def="dt-application">applications</termref>.
	The DOM is designed to be used with any programming
	language. In order to provide a precise, language-independent
	specification of the DOM interfaces, we have chosen to define
	the specifications in Object Management Group (OMG) IDL <bibref
	ref="OMGIDL"/>, as defined in the CORBA 2.3.1 specification <bibref
	ref="CORBA"/>. In addition to the OMG IDL specification, we provide
	<termref def="dt-lang-binding">language bindings</termref> for Java <bibref ref="Java"/> and ECMAScript <bibref
	ref="ECMAScript"/> (an industry-standard scripting
	language based on JavaScript <bibref ref="JavaScript"/> and JScript
	<bibref ref='JScript'/>).</p>
	<note><p>OMG IDL is used only as a language-independent and
	implementation-neutral way to specify <termref def="dt-interface">interfaces</termref>. Various other
	IDLs could have been used (<bibref ref="COM"/>, <bibref
	ref="JavaIDL"/>, <bibref ref="MSIDL"/>, ...). In general, IDLs
	are designed for specific computing environments. The Document Object
	Model can be implemented in any computing environment, and does not
	require the object binding runtimes generally associated with
	such IDLs.
	</p></note>

	</div2>
	<div2 id="ID-E7C30821">
	<head>What the Document Object Model is</head>
	<p>The DOM is a programming <termref def="dt-API">API</termref> for documents.
	It is based on an object structure that closely resembles the structure of the
	documents it <termref def="dt-model">models</termref>. For instance, consider this table, taken
	from an HTML document: </p>
	<eg role="code">
	<TABLE>
	<TBODY>
	<TR>
	<TD>Shady Grove</TD>
	<TD>Aeolian</TD>
	</TR>
	<TR>
	<TD>Over the River, Charlie</TD>
	<TD>Dorian</TD>
	</TR>
	</TBODY>
	</TABLE>
	</eg>
	<p>A graphical representation of the DOM of the example table is:
	<graphic source="./images/table.gif" alt="graphical representation of the
	DOM of the example table"/>
	</p>
	<p>In the DOM, documents have a logical
	structure which is very much like a tree; to be more precise, which is
	like a "forest" or "grove",
	which can contain more than one tree. Each document contains zero or one
	doctype nodes, one root element node, and zero or more comments
	or processing instructions; the root element serves as the root
	of the element tree for the document. However, the DOM
	does not specify that documents must be <emph>implemented</emph> as a
	tree or a grove<!--but not the same as an sgml grove-->, nor
	does it specify how the relationships among objects be
	implemented. The DOM is a logical model that may be implemented in any
	convenient manner. In this
	specification, we use the term <emph>structure model</emph> to
	describe the tree-like representation of a document.
	We also use the term "tree" when referring to the arrangement of
	those information items which can be reached by using "tree-walking"
	methods; (this does not include attributes).
	One important property of DOM structure models
	is <emph>structural isomorphism</emph>: if any two Document
	Object Model implementations are used to create a representation
	of the same document, they will create the same structure model,
	in accordance with the XML Information Set <bibref ref="InfoSet"/>.</p>
	<note><p>There may be some variations depending on the parser being
	used to build the DOM. For instance, the DOM may not contain
	whitespaces in element content if the parser discards them.</p>
	</note>
	<p>The name "Document Object Model" was chosen because
	it is an "<termref def="dt-object-model">object model</termref>" in the traditional
	object oriented design sense: documents are modeled using
	objects, and the model encompasses not only the structure of a
	document, but also the behavior of a document and the objects
	of which it is composed. In other words, the nodes in the
	above diagram do not represent a data structure, they
	represent objects, which have functions and identity. As an
	object model, the DOM identifies:</p>
	<ulist>
	<item><p>the interfaces and objects used to represent and manipulate
	a document</p></item>
	<item><p>the semantics of these interfaces and objects - including
	both behavior and attributes</p></item>
	<item><p>the relationships and collaborations among these interfaces
	and objects</p></item>
	</ulist>

	<p>The structure of SGML documents has traditionally been
	represented by an abstract <termref def="dt-datamodel">data model</termref>, not by an object model.
	In an abstract <termref def="dt-datamodel">data model</termref>, the model is centered around the
	data. In object oriented programming languages, the data itself
	is encapsulated in objects that hide the data, protecting it
	from direct external manipulation. The functions associated with
	these objects determine how the objects may be manipulated, and
	they are part of the object model.</p>

	</div2>
	<div2 id="ID-E7C30822">
	<head>What the Document Object Model is not</head>
	<p>This section is designed to give a more precise understanding
	of the DOM by distinguishing it from other
	systems that may seem to be like it.</p>
	<ulist>
	<item><p>The Document Object Model is not a binary specification.
	DOM programs written in the same language binding will be
	source code compatible across platforms, but the DOM
	does not define any form of binary interoperability.</p></item>
	<item><p>The Document Object Model is not a way of persisting objects
	to XML or HTML. Instead of specifying how objects may be
	represented in XML, the DOM specifies how
	XML and HTML documents are represented as objects, so that
	they may be used in object oriented programs.</p></item>
	<item><p>The Document Object Model is not a set of data structures;
	it is an <termref def="dt-object-model">object model</termref> that specifies interfaces. Although this
	document contains diagrams showing parent/child relationships,
	these are logical relationships defined by the programming
	interfaces, not representations of any particular internal
	data structures.</p></item>
	<item><p>The Document Object Model does not define what information in a
	document is relevant or how information in a document is
	structured. For XML, this is specified by the W3C XML Information Set
	<bibref ref="InfoSet"/>. The DOM is simply an <termref def="dt-API">API</termref> to this information
	set.</p></item>
	<item><p>The Document Object Model, despite its name, is not a
	competitor to the Component Object Model (COM). COM, like
	CORBA, is a language independent way to specify interfaces and
	objects; the DOM is a set of interfaces and
	objects designed for managing HTML and XML documents. The DOM
	may be implemented using language-independent systems like COM
	or CORBA; it may also be implemented using language-specific
	bindings like the Java or ECMAScript bindings specified in
	this document.</p></item>
	</ulist>
	</div2>
	<div2 id="ID-E7C30823">
	<head>Where the Document Object Model came from</head>
	<p>The DOM originated as a specification to
	allow JavaScript scripts and Java programs to be portable among
	Web browsers. "Dynamic HTML" was the immediate ancestor of the
	Document Object Model, and it was originally thought of largely
	in terms of browsers. However, when the DOM
	Working Group was formed at W3C, it was also joined by vendors in other
	domains, including HTML or XML editors and document
	repositories. Several of these vendors had worked with SGML
	before XML was developed; as a result, the DOM
	has been influenced by SGML Groves and the HyTime standard. Some
	of these vendors had also developed their own object models for
	documents in order to provide an API for SGML/XML
	editors or document repositories, and these object models have
	also influenced the DOM.</p>
	</div2>


	<div2 id="ID-E7C30824"><head>Entities and the DOM Core</head>
	<p>In the fundamental DOM interfaces, there are no objects representing
	entities. Numeric character references, and references to the
	pre-defined entities in HTML and XML, are replaced by the
	single character that makes up the entity's replacement.
	For example, in:
	</p>
	<eg role="code">
	<p>This is a dog &amp; a cat</p>
	</eg>
	<p>
	the "&amp;" will be replaced by the character "&", and the text
	in the P element will form a single continuous sequence of
	characters. Since numeric character references and pre-defined entities
	are not recognized as such in CDATA sections, or in the SCRIPT and STYLE
	elements in HTML, they are not replaced by the single character they
	appear to refer to. If the example above were enclosed in a CDATA
	section, the "&amp;" would not be replaced by "&"; neither would
	the <p> be recognized as a start tag. The representation of general
	entities, both internal and external, are defined within the
	extended (XML) interfaces of DOM Level 1 <bibref ref='DOM-Level-1'/>.</p>
	<p>
	Note: When a DOM representation of a document is serialized
	as XML or HTML text, applications will need to check each
	character in text data to see if it needs to be escaped
	using a numeric or pre-defined entity. Failing to do so
	could result in invalid HTML or XML. Also, <termref
	def="dt-implementation">implementations</termref> should be
	aware of the fact that serialization into a character encoding
	("charset") that does not fully cover ISO 10646 may fail if there are
	characters in markup or CDATA sections that are not present in the
	encoding.</p>
	</div2>

	<div2 id="ID-Conformance">
	<head>Conformance</head>
	<p>
	This section explains the different levels of conformance to DOM Level 2.
	DOM Level 2 consists of 14 modules. It is possible to conform to DOM
	Level 2, or to a DOM Level 2 module.
	</p>

	<p>
	An implementation is DOM Level 2 conformant if it supports the Core
	module defined in this document (see <specref ref="ID-BBACDC08"/>). An
	implementation conforms to a DOM Level 2 module if it supports all the
	interfaces for that module and the associated semantics.
	</p>
	<p>
	Here is the complete list of DOM Level 2.0 modules and the features used
	by them. Feature names are case-insensitive.
	</p>

	<glist>
	<gitem>
	<label>Core module</label>
	<def>
	<p>
	defines the feature <xspecref
	href="core.html#ID-BBACDC08">"Core"</xspecref>.
	</p>
	</def>
	</gitem>
	<gitem>
	<label>XML module</label>
	<def>
	<p>
	defines the feature <xspecref
	href="core.html#ID-E067D597">"XML"</xspecref>.
	</p>
	</def>
	</gitem>
	<gitem>
	<label>HTML module</label>
	<def>
	<p>defines the feature "HTML". (see <bibref ref="DOMHTML-inf"/>).</p>
	<note>
	<p>At time of publication, this DOM Level 2 module is not yet a W3C Recommendation.</p>
	</note>
	</def>
	</gitem>
	<gitem>
	<label>Views module</label>
	<def>
	<p>defines the feature <xspecref
	href='&views.latest.url;/views.html'>"Views"</xspecref> in <bibref ref="DOMViews-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Style Sheets module</label>
	<def>
	<p>defines the feature <xspecref
	href='&style.latest.url;/stylesheets.html'>"StyleSheets"</xspecref> in <bibref ref="DOMStyleSheets-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>CSS module</label>
	<def>
	<p>defines the feature <xspecref
	href='&style.latest.url;/css.html'>"CSS"</xspecref> in <bibref ref="DOMCSS-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>CSS2 module</label>
	<def>
	<p>defines the feature <xspecref
	href='&style.latest.url;/css.html'>"CSS2"</xspecref> in <bibref ref="DOMCSS-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Events module</label>
	<def>
	<p>defines the feature <xspecref
	href='&events.latest.url;/events.html'>"Events"</xspecref> in <bibref ref="DOMEvents-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>User interface Events module</label>
	<def>
	<p>defines the feature <xspecref
	href='&events.latest.url;/events.html'>"UIEvents"</xspecref> in <bibref ref="DOMEvents-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Mouse Events module</label>
	<def>
	<p>defines the feature <xspecref
	href='&events.latest.url;/events.html'>"MouseEvents"</xspecref> in <bibref ref="DOMEvents-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Mutation Events module</label>
	<def>
	<p>defines the feature <xspecref
	href='&events.latest.url;/events.html'>"MutationEvents"</xspecref> in <bibref ref="DOMEvents-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>HTML Events module</label>
	<def>
	<p>defines the feature <xspecref
	href='&events.latest.url;/events.html'>"HTMLEvents"</xspecref> in <bibref ref="DOMEvents-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Range module</label>
	<def>
	<p>defines the feature <xspecref
	href='&traversal-range.latest.url;/ranges.html'>"Range"</xspecref> in <bibref ref="DOMRange-inf"/>.</p>
	</def>
	</gitem>
	<gitem>
	<label>Traversal module</label>
	<def>
	<p>defines the feature <xspecref
	href='&traversal-range.latest.url;/traversal.html'>"Traversal"</xspecref> in <bibref ref="DOMTraversal-inf"/>.</p>
	</def>
	</gitem>
	</glist>

	<p>
	A DOM implementation must not return <code>"true"</code> to the
	<code>hasFeature(feature, version)</code> <termref
	def="dt-method">method</termref> of the <code>DOMImplementation</code>
	interface for that feature unless the implementation conforms to that
	module. The <code>version</code> number for all features used in DOM
	Level 2.0 is "2.0".
	</p>

	</div2>

	<div2 id="ID-E7C30826"><head>DOM Interfaces and DOM Implementations</head>

	<p>The DOM specifies interfaces which may be used to manage XML or
	HTML documents. It is important to realize that these interfaces
	are an abstraction - much like "abstract base classes" in C++,
	they are a means of specifying a way to access and manipulate an
	application's internal representation of a document. Interfaces
	do not imply a particular concrete
	implementation. Each DOM application is free to maintain
	documents in any convenient representation, as long as the
	interfaces shown in this specification are supported. Some
	DOM implementations will be existing programs that use the
	DOM interfaces to access software written long before the
	DOM specification existed. Therefore, the DOM is designed
	to avoid implementation dependencies; in particular,</p>
	<olist>
	<item><p>Attributes defined in the IDL do not imply concrete
	objects which must have specific data members - in the
	language bindings, they are translated to a pair of
	get()/set() functions, not to a data member. Read-only
	attributes have only a get() function in the language
	bindings. </p>
	</item>
	<item><p>DOM applications may provide additional interfaces
	and objects not found in this specification and still be
	considered DOM conformant.</p></item>
	<item><p>Because we specify interfaces and not the actual
	objects that are to be created, the DOM cannot know what
	constructors to call for an implementation. In general,
	DOM users call the createX() methods on the Document
	class to create document structures, and DOM
	implementations create their own internal representations
	of these structures in their implementations of the
	createX() functions.
	</p></item>
	</olist>
	<p>
	The Level 1 interfaces were extended to provide both Level 1 and Level 2
	functionality.
	</p>
	<p>
	DOM implementations in languages other than Java or ECMAScript may
	choose bindings that are appropriate and natural for their language and
	run time environment. For example, some systems may need to create a
	Document2 class which inherits from Document and contains the new methods
	and attributes.
	</p>
	<p>DOM Level 2 does not specify multithreading mechanisms.</p>
	</div2>
	</div1>
	<!--
	*************************************************************************
	* END OF DOM INTRODUCTION *
	*************************************************************************
	-->