`
` REC-DOM-Level-1-19981001
`
`Document Object Model (DOM) Level 1 Specification
`
`Version 1.0
`
`W3C Recommendation 1 October, 1998
`
`This version
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/DOM.ps
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/DOM.pdf
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/DOM.tgz
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/DOM.zip
`http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/DOM.txt
`Latest version
`http://www.w3.org/TR/REC-DOM-Level-1
`Previous versions
`http://www.w3.org/TR/1998/PR-DOM-Level-1-19980818
`http://www.w3.org/TR/1998/WD-DOM-19980720
`http://www.w3.org/TR/1998/WD-DOM-19980416
`http://www.w3.org/TR/WD-DOM-19980318
`http://www.w3.org/TR/WD-DOM-971209
`http://www.w3.org/TR/WD-DOM-971009
`
`WG Chair
`Lauren Wood, SoftQuad, Inc.
`Editors
`Vidur Apparao, Netscape
`Steve Byrne, Sun
`Mike Champion, ArborText
`Scott Isaacs, Microsoft
`Ian Jacobs, W3C
`Arnaud Le Hors, W3C
`Gavin Nicol, Inso EPS
`Jonathan Robie, Texcel Research
`Robert Sutor, IBM
`Chris Wilson, Microsoft
`Lauren Wood, SoftQuad, Inc.
`Principal Contributors
`Vidur Apparao, Netscape
`Steve Byrne, Sun (until November 1997)
`Mike Champion, ArborText, Inc.
`
`1
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 1 of 169
`
`
`
`Status of this document
`
`Scott Isaacs, Microsoft (until January, 1998)
`Arnaud Le Hors, W3C
`Gavin Nicol, Inso EPS
`Jonathan Robie, Texcel Research
`Peter Sharpe, SoftQuad, Inc.
`Bill Smith, Sun (after November 1997)
`Jared Sorensen, Novell
`Robert Sutor, IBM
`Ray Whitmer, iMall
`Chris Wilson, Microsoft (after January, 1998)
`
`Status of this document
`
`This document has been reviewed by W3C Members and other interested parties and has been endorsed
`by the Director as a W3C Recommendation. It is a stable document and may be used as reference material
`or cited as a normative reference from another document. W3C’s role in making the Recommendation is
`to draw attention to the specification and to promote its widespread deployment. This enhances the
`functionality and interoperability of the Web.
`
`The authors of this document are the DOM Working Group members, different chapters may have
`different editors.
`
`Comments on this document should be sent to the public mailing list www-dom@w3.org.
`
`A list of current W3C Recommendations and other technical documents can be found at
`http://www.w3.org/TR.
`
`Errata
`
`The list of known errors in this document is found at
`http://www.w3.org/DOM/updates/REC-DOM-Level-1-19981001-errata.html.
`
`Available Languages
`
`The English version of this specification is the only normative version. However, for translations in other
`languages see http://www.w3.org/DOM/updates/REC-DOM-Level-1-translations.html.
`
`Abstract
`
`This specification defines the Document Object Model Level 1, a platform- and language-neutral interface
`that allows programs and scripts to dynamically access and update the content, structure and style of
`documents. The Document Object Model provides a standard set of objects for representing HTML and
`XML documents, a standard model of how these objects can be combined, and a standard interface for
`accessing and manipulating them. Vendors can support the DOM as an interface to their proprietary data
`structures and APIs, and content authors can write to the standard DOM interfaces rather than
`product-specific APIs, thus increasing interoperability on the Web.
`
`2
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 2 of 169
`
`
`
`Table of contents
`
`The goal of the DOM specification is to define a programmatic interface for XML and HTML. The DOM
`Level 1 specification is separated into two parts: Core and HTML. The Core DOM Level 1 section
`provides a low-level set of fundamental interfaces that can represent any structured document, as well as
`defining extended interfaces for representing an XML document. These extended XML interfaces need
`not be implemented by a DOM implementation that only provides access to HTML documents; all of the
`fundamental interfaces in the Core section must be implemented. A compliant DOM implementation that
`implements the extended XML interfaces is required to also implement the fundamental Core interfaces,
`but not the HTML interfaces. The HTML Level 1 section provides additional, higher-level interfaces that
`are used with the fundamental interfaces defined in the Core Level 1 section to provide a more convenient
`view of an HTML document. A compliant implementation of the HTML DOM implements all of the
`fundamental Core interfaces as well as the HTML interfaces.
`
`Table of contents
`
`Expanded Table of Contents
`.
`.
`Copyright Notice
`.
`.
`.
`.
`.
`What is the Document Object Model?
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Chapter 1: Document Object Model (Core) Level 1
`Chapter 2: Document Object Model (HTML) Level 1
`
`.
`.
`.
`.
`.
`Appendix A: Contributors
`Appendix B: Glossary
`.
`.
`.
`.
`.
`Appendix C: IDL Definitions
`.
`.
`.
`.
`Appendix D: Java Language Binding
`.
`.
`Appendix E: ECMA Script Language Binding
`References
`.
`.
`.
`.
`.
`.
`.
`.
`Index
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Production Notes (Non-Normative)
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`5
`7
`9
`
`.15
`
`
`.49
`
`.95
`
`
`.97
`
`.103
`
`.117
`
`.135
`
`.161
`
`.163
`
`.167
`
`3
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 3 of 169
`
`
`
`Table of contents
`
`4
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 4 of 169
`
`
`
`Expanded Table of Contents
`
`Expanded Table of Contents
`Expanded Table of Contents
`.
`.
`.
`.
`.
`Copyright Notice
`.
`.
`.
`.
`.
`.
`.
`.
`What is the Document Object Model?
`.
`.
`.
`Introduction
`.
`.
`.
`.
`.
`.
`.
`.
`What the Document Object Model is
`.
`.
`What the Document Object Model is not
`.
`Where the Document Object Model came from
`Entities and the DOM Core
`.
`.
`.
`.
`DOM Interfaces and DOM Implementations
`Limitations of Level 1
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`Chapter 1: Document Object Model (Core) Level 1
`.
`1.1. Overview of the DOM Core Interfaces
`.
`.
`1.1.1. The DOM Structure Model
`.
`.
`.
`1.1.2. Memory Management
`.
`.
`.
`.
`1.1.3. Naming Conventions
`.
`.
`.
`.
`1.1.4. Inheritance vs Flattened Views of the API
`1.1.5. The DOMString type
`.
`.
`.
`.
`.
`1.1.6. Case sensitivity in the DOM
`.
`.
`.
`.
`1.2. Fundamental Interfaces
`.
`.
`.
`.
`.
`.
`1.3. Extended Interfaces
`.
`.
`.
`.
`.
`.
`.
`Chapter 2: Document Object Model (HTML) Level 1
`.
`.
`2.1. Introduction
`.
`.
`.
`.
`.
`.
`.
`.
`.
`2.2. HTML Application of Core DOM
`.
`.
`.
`.
`2.2.1. Naming Conventions
`.
`.
`.
`.
`.
`2.3. Miscellaneous Object Definitions
`.
`.
`.
`.
`2.4. Objects related to HTML documents
`.
`.
`.
`2.5. HTML Elements
`.
`.
`.
`.
`.
`.
`.
`.
`2.5.1. Property Attributes
`.
`.
`.
`.
`.
`.
`2.5.2. Naming Exceptions
`.
`.
`.
`.
`.
`2.5.3. Exposing Element Type Names (tagName)
`2.5.4. The HTMLElement interface
`.
`.
`.
`2.5.5. Object definitions
`.
`.
`.
`.
`.
`.
`
`Appendix A: Contributors
`.
`.
`.
`.
`.
`.
`Appendix B: Glossary
`.
`.
`.
`.
`.
`.
`Appendix C: IDL Definitions
`.
`.
`.
`.
`.
`C.1. Document Object Model Level 1 Core
`.
`C.2. Document Object Model Level 1 HTML
`Appendix D: Java Language Binding
`.
`.
`.
`D.1. Document Object Model Level 1 Core
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`5
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`5
`.
`7
`.
`9
`.
`
`.10
`
`.10
`
`.12
`
`.12
`
`.12
`
`.13
`
`.14
`
`.15
`
`
`.16
`
`.16
`
`.16
`
`.17
`
`.17
`
`.18
`
`.18
`
`.19
`
`.43
`
`.49
`
`.50
`
`.50
`
`.50
`
`.51
`
`.52
`
`.55
`
`.55
`
`.55
`
`.56
`
`.56
`
`.57
`
`.95
`
`
`.97
`
`.103
`
`.103
`
`.106
`
`.117
`
`.117
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 5 of 169
`
`
`
`Expanded Table of Contents
`
`D.2. Document Object Model Level 1 HTML
`Appendix E: ECMA Script Language Binding
`.
`E.1. Document Object Model Level 1 Core
`.
`E.2. Document Object Model Level 1 HTML
`References
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Index
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Production Notes (Non-Normative)
`.
`.
`.
`.
`1. The Document Type Definition
`.
`.
`.
`2. The production process
`.
`.
`.
`.
`.
`3. Object Definitions
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.120
`
`
`.135
`
`.135
`
`.139
`
`.161
`
`.163
`
`.167
`
`.168
`
`.168
`
`.169
`
`6
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 6 of 169
`
`
`
`Copyright Notice
`
`Copyright Notice
`Copyright © 1998 World Wide Web Consortium , (Massachusetts Institute of Technology , Institut
`National de Recherche en Informatique et en Automatique , Keio University ). All Rights Reserved.
`
`Documents on the W3C site are provided by the copyright holders under the following license. By
`obtaining, using and/or copying this document, or the W3C document from which this statement is linked,
`you agree that you have read, understood, and will comply with the following terms and conditions:
`
`Permission to use, copy, and distribute the contents of this document, or the W3C document from which
`this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted,
`provided that you include the following on ALL copies of the document, or portions thereof, that you use:
`
`1. A link or URI to the original W3C document.
`2. The pre-existing copyright notice of the original author, if it doesn’t exist, a notice of the form:
`"Copyright © World Wide Web Consortium , (Massachusetts Institute of Technology , Institut
`National de Recherche en Informatique et en Automatique , Keio University ). All Rights Reserved."
`3. If it exists, the STATUS of the W3C document.
`
`When space permits, inclusion of the full text of this NOTICE should be provided. In addition, credit
`shall be attributed to the copyright holders for any software, documents, or other items or products that
`you create pursuant to the implementation of the contents of this document, or any portion thereof.
`
`No right to create modifications or derivatives is granted pursuant to this license.
`
`THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO
`REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT
`LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
`PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE
`DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION
`OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS,
`COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
`
`COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL
`OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR
`THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
`
`The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to
`this document or its contents without specific, written prior permission. Title to copyright in this
`document will at all times remain with copyright holders.
`
`7
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 7 of 169
`
`
`
`Copyright Notice
`
`8
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 8 of 169
`
`
`
`What is the Document Object Model?
`
`What is the Document Object Model?
`Editors
`Jonathan Robie, Texcel Research
`
`9
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 9 of 169
`
`
`
`Introduction
`
`Introduction
`
`The Document Object Model (DOM) is an application programming interface (API) for HTML and XML
`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.
`
`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 interfaces for the XML internal and external subsets have not yet been specified.
`
`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 applications. 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 OMG IDL, as defined
`in the CORBA 2.2 specification. In addition to the OMG IDL specification, we provide language bindings
`for Java and ECMAScript (an industry-standard scripting language based on JavaScript and JScript).
`Note: OMG IDL is used only as a language-independent and implementation-neutral way to specify
`interfaces. Various other IDLs could have been used. 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.
`
`What the Document Object Model is
`
`The DOM is a programming API for documents. It closely resembles the structure of the documents it
`models. For instance, consider this table, taken from an HTML document:
`
` <TABLE>
` <TBODY>
` <TR>
` <TD>Shady Grove</TD>
` <TD>Aeolian</TD>
` </TR>
` <TR>
` <TD>Over the River, Charlie</TD>
` <TD>Dorian</TD>
` </TR>
` </TBODY>
` </TABLE>
`
`The DOM represents this table like this:
`
`10
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 10 of 169
`
`
`
`What the Document Object Model is
`
`DOM representation of the example table
`
`In the DOM, documents have a logical structure which is very much like a tree; to be more precise, it is
`like a "forest" or "grove", which can contain more than one tree. However, the DOM does not specify that
`documents must be implemented as a tree or a 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 structure model to describe the tree-like representation of a
`document; we specifically avoid terms like "tree" or "grove" in order to avoid implying a particular
`implementation. One important property of DOM structure models is structural isomorphism: if any two
`Document Object Model implementations are used to create a representation of the same document, they
`will create the same structure model, with precisely the same objects and relationships.
`
`The name "Document Object Model" was chosen because it is an "object model" 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:
`
`the interfaces and objects used to represent and manipulate a document
`the semantics of these interfaces and objects - including both behavior and attributes
`the relationships and collaborations among these interfaces and objects
`
`The structure of SGML documents has traditionally been represented by an abstract data model, not by an
`object model. In an abstract data model, 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.
`
`The Document Object Model currently consists of two parts, DOM Core and DOM HTML. The DOM
`Core represents the functionality used for XML documents, and also serves as the basis for DOM HTML.
`A compliant implementation of the DOM must implement all of the fundamental interfaces in the Core
`chapter with the semantics as defined. Further, it must implement at least one of the HTML DOM and the
`
`11
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 11 of 169
`
`
`
`What the Document Object Model is not
`
`extended (XML) interfaces with the semantics as defined.
`
`What the Document Object Model is not
`
`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.
`
`Although the Document Object Model was strongly influenced by "Dynamic HTML", in Level 1, it
`does not implement all of "Dynamic HTML". In particular, events have not yet been defined. Level 1
`is designed to lay a firm foundation for this kind of functionality by providing a robust, flexible
`model of the document itself.
`The Document Object Model is not a binary specification. DOM programs written in the same
`language will be source code compatible across platforms, but the DOM does not define any form of
`binary interoperability.
`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.
`The Document Object Model is not a set of data structures, it is an object model 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.
`The Document Object Model does not define "the true inner semantics" of XML or HTML. The
`semantics of those languages are defined by W3C Recommendations for these languages. The DOM
`is a programming model designed to respect these semantics. The DOM does not have any
`ramifications for the way you write XML and HTML documents; any document that can be written
`in these languages can be represented in the DOM.
`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.
`
`Where the Document Object Model came from
`
`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.
`
`12
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 12 of 169
`
`
`
`Entities and the DOM Core
`
`Entities and the DOM Core
`
`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>This is a dog & a cat</p>
`
`the "&" 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 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 "&" 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 the Level 1 specification.
`
`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, implementations 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.
`
`DOM Interfaces and DOM Implementations
`
`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,
`
`1. 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 functions have only a get() function in the language bindings).
`2. DOM applications may provide additional interfaces and objects not found in this specification and
`still be considered DOM compliant.
`3. Because we specify interfaces and not the actual objects that are to be created, the DOM can not
`know what constructors to call for an implementation. In general, DOM users call the createXXX()
`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 createXXX()
`functions.
`
`13
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 13 of 169
`
`
`
`Limitations of Level 1
`
`Limitations of Level 1
`
`The DOM Level 1 specification is intentionally limited to those methods needed to represent and
`manipulate document structure and content. The plan is for future Levels of the DOM specification to
`provide:
`
`1. A structure model for the internal subset and the external subset.
`2. Validation against a schema.
`3. Control for rendering documents via style sheets.
`4. Access control.
`5. Thread-safety.
`6. Events.
`
`14
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 14 of 169
`
`
`
`1. Document Object Model (Core) Level 1
`
`1. Document Object Model (Core) Level 1
`Editors
`Mike Champion, ArborText (from November 20, 1997)
`Steve Byrne, JavaSoft (until November 19, 1997)
`Gavin Nicol, Inso EPS
`Lauren Wood, SoftQuad, Inc.
`
`15
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 15 of 169
`
`
`
`1.1. Overview of the DOM Core Interfaces
`
`1.1. Overview of the DOM Core Interfaces
`
`This section defines a minimal set of objects and interfaces for accessing and manipulating document
`objects. The functionality specified in this section (the Core functionality) should be sufficient to allow
`software developers and web script authors to access and manipulate parsed HTML and XML content
`inside conforming products. The DOM Core API also allows population of a Document [p.22] object
`using only DOM API calls; creating the skeleton Document [p.22] and saving it persistently is left to the
`product that implements the DOM API.
`
`1.1.1. The DOM Structure Model
`
`The DOM presents documents as a hierarchy of Node [p.25] objects that also implement other, more
`specialized interfaces. Some types of nodes may have child nodes of various types, and others are leaf
`nodes that cannot have anything below them in the document structure. The node types, and which node
`types they may have as children, are as follows:
`
`Document [p.22] -- Element [p.38] (maximum of one), ProcessingInstruction [p.46] ,
`Comment [p.43] , DocumentType [p.44]
`DocumentFragment [p.21] -- Element [p.38] , ProcessingInstruction [p.46] ,
`Comment [p.43] , Text [p.42] , CDATASection [p.43] , EntityReference [p.46]
`DocumentType [p.44] -- no children
`EntityReference [p.46] -- Element [p.38] , ProcessingInstruction [p.46] , Comment
`[p.43] , Text [p.42] , CDATASection [p.43] , EntityReference [p.46]
`Element [p.38] -- Element [p.38] , Text [p.42] , Comment [p.43] ,
`ProcessingInstruction [p.46] , CDATASection [p.43] , EntityReference [p.46]
`Attr [p.37] -- Text [p.42] , EntityReference [p.46]
`ProcessingInstruction [p.46] -- no children
`Comment [p.43] -- no children
`Text [p.42] -- no children
`CDATASection [p.43] -- no children
`Entity [p.45] -- Element [p.38] , ProcessingInstruction [p.46] , Comment [p.43] ,
`Text [p.42] , CDATASection [p.43] , EntityReference [p.46]
`Notation [p.44] -- no children
`
`The DOM also specifies a NodeList [p.32] interface to handle ordered lists of Node [p.25] s, such as
`the children of a Node [p.25] , or the elements returned by the Element.getElementsByTagName
`method, and also a NamedNodeMap [p.32] interface to handle unordered sets of nodes referenced by
`their name attribute, such as the attributes of an Element [p.38] . NodeList [p.32] s and
`NamedNodeMap [p.32] s in the DOM are "live", that is, changes to the underlying document structure
`are reflected in all relevant NodeList [p.32] s and NamedNodeMap [p.32] s. For example, if a DOM
`user gets a NodeList [p.32] object containing the children of an Element [p.38] , then subsequently
`adds more children to that element (or removes children, or modifies them), those changes are
`automatically reflected in the NodeList [p.32] without further action on the user’s part. Likewise
`changes to a Node [p.25] in the tree are reflected in all references to that Node [p.25] in NodeList
`[p.32] s and NamedNodeMap [p.32] s.
`
`16
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 16 of 169
`
`
`
`1.1.2. Memory Management
`
`1.1.2. Memory Management
`
`Most of the APIs defined by this specification are interfaces rather than classes. That means that an actual
`implementation need only expose methods with the defined names and specified operation, not actually
`implement classes that correspond directly to the interfaces. This allows the DOM APIs to be
`implemented as a thin veneer on top of legacy applications with their own data structures, or on top of
`newer applications with different class hierarchies. This also means that ordinary constructors (in the Java
`or C++ sense) cannot be used to create DOM objects, since the underlying objects to be constructed may
`have little relationship to the DOM interfaces. The conventional solution to this in object-oriented design
`is to define factory methods that create instances of objects that implement the various interfaces. In the
`DOM Level 1, objects implementing some interface "X" are created by a "createX()" method on the
`Document [p.22] interface; this is because all DOM objects live in the context of a specific Document.
`
`The DOM Level 1 API does not define a standard way to create DOMImplementation [p.20] or
`Document [p.22] objects; actual DOM implementations must provide some proprietary way of
`bootstrapping these DOM interfaces, and then all other objects can be built from the Create methods on
`Document [p.22] (or by various other convenience methods).
`
`The Core DOM APIs are designed to be compatible with a wide range of languages, including both
`general-user scripting languages and the more challenging languages used mostly by professional
`programmers. Thus, the DOM APIs need to operate across a variety of memory management
`philosophies, from language platforms that do not expose memory management to the user at all, through
`those (notably Java) that provide explicit constructors but provide an automatic garbage collection
`mechanism to automatically reclaim unused memory, to those (especially C/C++) that generally require
`the programmer to explicitly allocate object memory, track where it is used, and explicitly free it for
`re-use. To ensure a consistent API across these platforms, the DOM does not address memory
`management issues at all, but instead leaves these for the implementation. Neither of the explicit language
`bindings devised by the DOM Working Group (for ECMAScript and Java) require any memory
`management methods, but DOM bindings for other languages (especially C or C++) probably will require
`such support. These extensions will be the responsibility of those adapting the DOM API to a specific
`language, not the DOM WG.
`
`1.1.3. Naming Conventions
`
`While it would be nice to have attribute and method names that are short, informative, internally
`consistent, and familiar to users of similar APIs, the names also should not clash with the names in legacy
`APIs supported by DOM implementations. Furthermore, both OMG IDL and ECMAScript have
`significant limitations in their ability to disambiguate names from different namespaces that makes it
`difficult to avoid naming conflicts with short, familiar names. So, DOM names tend to be long and quite
`descriptive in order to be unique across all environments.
`
`The Working Group has also attempted to be internally consistent in its use of various terms, even though
`these may not be common distinctions in other APIs. For example, we use the method name "remove"
`when the method changes the structural model, and the method name "delete" when the method gets rid of
`something inside the structure model. The thing that is deleted is not returned. The thing that is removed
`may be returned, when it makes sense to return it.
`
`17
`
`ACCESSIBE LTD EXHIBIT 1015
`Page 17 of 169
`
`
`
`1.1.4. Inheritance vs Flattened Views of the API
`
`1.1.4. Inheritance vs Flattened Views of the API
`
`The DOM Core APIs present two somewhat different sets of interfaces to an XML/HTML document; one
`presenting an "object oriented" approach with a hierarchy of inheritance, and a "simplified" view that
`allows all manipulation to be done via the Node [p.25] interface without requiring casts (in Java and other
`C-like languages) or query interface calls in COM environments. These operations are fairly expensive in
`Java and COM, and the DOM may be used in performance-critical environments, so we allow significant
`functionality using just the Node [p.25] interface. Because many other users will find the inheritance
`hierarchy easier to understand than the "everything is a Node [p.25] " approach to the DOM, we also
`support the full higher-level interfaces for those who prefer a more object-oriented API.
`
`In practice, this means that there is a certain amount of redundancy in the API. The Working Group
`considers the "inheritance" approach the primary view of the API, and the full set of functionality on
`Node [p.25] to be "extra" functionality that users may employ, but that does not eliminate the need for
`methods on other interfaces that an object-oriented analysis would dictate. (Of course, when the O-O
`analysis yields an attribute or method that is identical to one on the Node [p.25] interface, we don’t
`specify a completely redundant one). Thus, even though there is a generic nodeName attribute on the
`Node [p.25] interface, there is still a tagName attribute on the Element [p.38] interface; these two
`attributes must contain the same value, but the Working Group considers it worthwhile to support both,
`given the different constituencies the DOM API must satisfy.
`
`1.1.5. The DOMString type
`
`To ensure interoperability, the DOM specifies the DOMString type as follows:
`
`A