NOTE-DOM-Requirements-20040226 64.5 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--
 Generated: Thu Feb 19 16:51:04 EST 2004 jfouffa.w3.org
 -->
<html lang='en-US' xml:lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Document Object Model (DOM) Requirements</title>
<link rel='stylesheet' type='text/css' href='./spec.css' />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel='stylesheet' type='text/css' href=
'http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css' />
<link rel='author' href='mailto:www-dom@w3.org' />
<link rel='help' href='http://www.w3.org/DOM/' />
</head>
<body>
<a id='Overview' name='Overview'></a>
<div class='head'>
<p><a href='http://www.w3.org/'><img height='48' width='72' alt=
'W3C' src='http://www.w3.org/Icons/w3c_home' /></a></p>
<h1 id='Overview-title'>Document Object Model (DOM)
Requirements</h1>
<!-- NOTE-DOM-Requirements-20040219 -->
<h2 id='Overview-W3C-doctype'>W3C Working Group Note 26 February
2004</h2>
<dl>
<dt>This version:</dt>
<dd><a href=
'http://www.w3.org/TR/2004/NOTE-DOM-Requirements-20040226'>http://www.w3.org/TR/2004/NOTE-DOM-Requirements-20040226</a></dd>
<dt>Latest version:</dt>
<dd><a href=
'http://www.w3.org/TR/DOM-Requirements'>http://www.w3.org/TR/DOM-Requirements</a></dd>
<dt>Previous version:</dt>
<dd><a href=
'http://www.w3.org/TR/2001/WD-DOM-Requirements-20010419'>http://www.w3.org/TR/2001/WD-DOM-Requirements-20010419</a></dd>
</dl>
<dl>
<dt>Editors:</dt>
<dd>Ben Chang, <i>Oracle</i></dd>
<dd>Philippe Le H&#233;garet, <i>W3C</i></dd>
<dd>Arnaud Le Hors, <i>IBM</i></dd>
<dd>Ray Whitmer, <i>Invited Expert, chair</i></dd>
<dd>Mike Champion, <i>Software AG (until 2003)</i></dd>
<dd>Tom Pixley, <i>Netscape Communications Corporation (until July
2002)</i></dd>
<dd>Joe Kesselman, <i>IBM (until 2001)</i></dd>
<dd>Andy Heninger, <i>IBM (until 2001)</i></dd>
<dd>Angel Diaz, <i>IBM (until 2001)</i></dd>
<dd>James Davidson, <i>Sun (until June 2000)</i></dd>
<dd>Lauren Wood, <i>SoftQuad Software Inc. (until November
2000)</i></dd>
<dd>Jared Sorensen, <i>Novell, Inc. (until January 1999)</i></dd>
</dl>
<p class='copyright'><a href=
'http://www.w3.org/Consortium/Legal/ipr-notice#Copyright'>Copyright</a>
&#169;2004 <a href='http://www.w3.org/'><abbr title=
'World Wide Web Consortium'>W3C</abbr></a><sup>&#174;</sup>
(<a href='http://www.csail.mit.edu/'><abbr title=
'Massachusetts Institute of Technology'>MIT</abbr></a>, <a href=
'http://www.ercim.org/'><abbr title=
'European Research Consortium for Informatics and Mathematics'>ERCIM</abbr></a>,
<a href='http://www.keio.ac.jp/'>Keio</a>), All Rights Reserved.
W3C <a href=
'http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer'>liability</a>,
<a href=
'http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks'>trademark</a>,
<a href=
'http://www.w3.org/Consortium/Legal/copyright-documents'>document
use</a> and <a href=
'http://www.w3.org/Consortium/Legal/copyright-software'>software
licensing</a> rules apply.</p>
</div>
<hr title='separator from header' />
<h2 id='Overview-abstract'>Abstract</h2>
<div class='abstract'>
<p>This document contains the requirements for the Document Object
Model, 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.</p>
</div>
<h2 id='Overview-status'>Status of this document</h2>
<div class='status'>
<p><em>This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest
revision of this technical report can be found in the <a href=
'http://www.w3.org/TR/'>W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>
<p>This document is a Working Group Note of the requirements of the
Document Object Model. Comments on this document are to be sent to
the public mailing list <a href=
'mailto:www-dom@w3.org'>www-dom@w3.org</a>. An archive is available
at <a href=
'http://lists.w3.org/Archives/Public/www-dom/'>http://lists.w3.org/Archives/Public/www-dom/</a>.
A list of <a href='http://www.w3.org/2001/10/23-DOMOpenList'>open
issues</a> has been published on 23 October 2001. Note that W3C is
not committed to work on the open issues.</p>
<p>Publication as a Working Group Note does not imply endorsement
by the W3C Membership. This is a draft document and may be updated,
replaced or obsoleted by other documents at any time.</p>
<p>This document has been produced as part of the <a href=
'http://www.w3.org/DOM/Activity.html'>W3C DOM Activity</a>. The
authors of this document are the DOM Working Group members.</p>
<p>Patent disclosures relevant to this specification may be found
on the DOM Working Group's <a href=
'http://www.w3.org/2002/08/02-DOM-Disclosures.html'>patent
disclosure page</a>.</p>
</div>
<a id='table-of-contents' name='table-of-contents'></a>
<div class='div1'><a name='table-of-contents-contents' id=
"table-of-contents-contents"></a>
<h1 id='table-of-contents-contents-h1' class='div1'>Table of
Contents</h1>
<ul class='toc'>
<li class='tocline2'><a class='tocxref' href=
'#table-of-contents'>Table of Contents</a></li>
</ul>
<ul class='toc'>
<li class='tocline2'><a class='tocxref' href=
'#general-requirements'>Chapter 1: General requirements</a>
<ul class='toc'>
<li class='tocline3'><a class='tocxref' href=
'#general-requirements-core'>1.1 Basic requirements</a></li>
<li class='tocline3'><a class='tocxref' href=
'#general-requirements-error'>1.2 Error Reporting</a></li>
</ul>
</li>
<li class='tocline2'><a class='tocxref' href=
'#dom-level-1-requirements'>Chapter 2: DOM Level 1 Requirements</a>
<ul class='toc'>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-1-requirements-Structure'>2.1 Structure Navigation</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-1-requirements-structure-general'>2.1.1 General
Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-1-requirements-structure-html'>2.1.2 HTML
Requirements</a></li>
</ul>
</li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-1-requirements-DocumentManipulation'>2.2 Document
Manipulation</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-1-requirements-ContentManipulation'>2.3 Content
Manipulation</a></li>
</ul>
</li>
<li class='tocline2'><a class='tocxref' href=
'#dom-level-2-requirements'>Chapter 3: DOM Level 2 Requirements</a>
<ul class='toc'>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-2-requirements-level2-eventmodel'>3.1 Event
Model</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-2-requirements-level2-stylesheet'>3.2 Stylesheet Object
Model</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-2-requirements-level2-range'>3.3 Range model</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-2-requirements-level2-traversal'>3.4 Traversal
model</a></li>
</ul>
</li>
<li class='tocline2'><a class='tocxref' href=
'#dom-level-3-requirements'>Chapter 4: DOM Level 3 Requirements</a>
<ul class='toc'>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-level3-core'>4.1 Core
Requirements</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Events-Requirements'>4.2 Level 3
Events Requirements</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Events-Requirements-eventGrouping'>
4.2.1 EventListener grouping</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Events-Requirements-keyEvents'>4.2.2
Key event set</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Events-Requirements-inputEvent'>4.2.3
Input event set</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Events-Requirements-deviceIndependent'>
4.2.4 Device independent event set</a></li>
</ul>
</li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-level3-CM'>4.3 Content Models and
Validation Use Cases and Requirements</a></li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-LS-Requirements'>4.4 Load and
Save Requirements</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-LS-General-Requirements'>4.4.1
General Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-LS-Load-Requirements'>4.4.2 Load
Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-LS-XML-Writer-Requirments'>4.4.3
XML Writer Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-LS-Other-Requirements'>4.4.4
Other Items Under Consideration</a></li>
</ul>
</li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-Level-3-Embedded'>4.5 Embedded DOM
Requirements</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-Abstract'>4.5.1 Abstract</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-Introduction'>4.5.2
Introduction</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-UseCases'>4.5.3 Use Cases</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-Scenarios'>4.5.4 Implementation
Scenarios</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-Requirements'>4.5.5
Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-EDOM-knownQuestions'>4.5.6 Known
Questions</a></li>
</ul>
</li>
<li class='tocline3'><a class='tocxref' href=
'#dom-level-3-requirements-level3-xpath'>4.6 XPath DOM Draft
Requirements</a>
<ul class='toc'>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-xpath-abstract'>4.6.1 Abstract</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-xpath-introduction'>4.6.2
Introduction</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-xpath-requirements'>4.6.3
Requirements</a></li>
<li class='tocline4'><a class='tocxref' href=
'#dom-level-3-requirements-xpath-issues'>4.6.4 Known
Questions</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
<!-- div1 contents -->
<a id='general-requirements' name='general-requirements'></a>
<div class='div1'><a name='general-requirements-General' id=
"general-requirements-General"></a>
<h1 id='general-requirements-General-h1' class='div1'>1. General
requirements</h1>
<div class='div2'><a name='general-requirements-core' id=
"general-requirements-core"></a>
<h2 id='general-requirements-core-h2' class='div2'>1.1 Basic
requirements</h2>
<ol>
<li>References to XML and HTML documents generally denote the
physical files that contain structural markup.</li>
<li>Where possible, the Level of the DOM in which the requirements
are met is noted.</li>
</ol>
<p>Listed below are the general requirements of the Document Object
Model.</p>
<ol>
<li>The Object Model is language neutral and platform
independent.</li>
<li>There will be a core DOM that is applicable to HTML, CSS and
XML documents.</li>
<li>The Object Model can be used to construct and deconstruct the
document.</li>
<li>The Object Model will not preclude use by either agents
external to the document content, or scripts embedded within the
document.</li>
<li>Consistent naming conventions must be used through all levels
of the Object Model.</li>
<li>A visual UI component will not be required for a conforming
implementation of the Object Model.</li>
<li>The specific HTML, CSS or XML document object models will be
driven by the underlying constructs of those languages.</li>
<li>It must be possible to read in a document and write out a
structurally isomorphic document.</li>
<li>The Object Model will not expose the user to problems with
security, validity, or privacy.</li>
<li>The Object Model will not preclude other mechanisms for
manipulating documents.</li>
</ol>
</div>
<!-- div2 core -->
<div class='div2'><a name='general-requirements-error' id=
"general-requirements-error"></a>
<h2 id='general-requirements-error-h2' class='div2'>1.2 Error
Reporting</h2>
<ol>
<li>Error reporting will be primarily via return values. Exceptions
will be raised on unrecoverable conditions.</li>
<li>The DOM will provide a document-wide reporting mechanism.
<em>[After Level 1]</em></li>
<li>The DOM error state can be queried. <em>[After Level
1]</em></li>
</ol>
</div>
<!-- div2 error --></div>
<!-- div1 General -->
<a id='dom-level-1-requirements' name=
'dom-level-1-requirements'></a>
<div class='div1'><a name='dom-level-1-requirements-Level1' id=
"dom-level-1-requirements-Level1"></a>
<h1 id='dom-level-1-requirements-Level1-h1' class='div1'>2. DOM
Level 1 Requirements</h1>
<div class='div2'><a name='dom-level-1-requirements-Structure' id=
"dom-level-1-requirements-Structure"></a>
<h2 id='dom-level-1-requirements-Structure-h2' class='div2'>2.1
Structure Navigation</h2>
<p>This refers to the navigation around a document, such as finding
the parent of a given element, or what children elements a given
parent element contains.</p>
<div class='div3'><a name=
'dom-level-1-requirements-structure-general' id=
"dom-level-1-requirements-structure-general"></a>
<h3 id='dom-level-1-requirements-structure-general-h3' class=
'div3'>2.1.1 General Requirements</h3>
<ol>
<li>All document content, including elements and attributes, will
be programmatically accessible and manipulable.</li>
<li>Navigation from any element to any other element will be
possible.</li>
<li>There will be a way to uniquely and reproducibly enumerate the
structure of static documents.</li>
<li>There will be a way to query for elements and attributes.
<em>[After Level 1]</em></li>
<li>Basic low-level functions (get first, get next, etc.) will be
provided, along with convenience functions that build upon them,
but have a consistent access method.</li>
</ol>
</div>
<!-- div3 structure-general -->
<div class='div3'><a name='dom-level-1-requirements-structure-html'
id="dom-level-1-requirements-structure-html"></a>
<h3 id='dom-level-1-requirements-structure-html-h3' class='div3'>
2.1.2 HTML Requirements</h3>
<p>These are specific to HTML document.</p>
<ol>
<li>All elements that are defined in the HTML 4.0 specification are
exposed. User agents may expose other elements using similar
interfaces.</li>
<li>Unknown tags and attributes are exposed.</li>
<li>Implied elements are exposed even if not explicitly defined in
the document (e.g., HTML, HEAD, BODY).</li>
</ol>
</div>
<!-- div3 structure-html --></div>
<!-- div2 Structure -->
<div class='div2'><a name=
'dom-level-1-requirements-DocumentManipulation' id=
"dom-level-1-requirements-DocumentManipulation"></a>
<h2 id='dom-level-1-requirements-DocumentManipulation-h2' class=
'div2'>2.2 Document Manipulation</h2>
<ol>
<li>There will be a way to add, remove and change elements and/or
tags in the document structure.</li>
<li>There will be a way to add, remove and change attributes in the
document structure.</li>
<li>Operations (or a combination of operations) must restore
consistency before they return.</li>
<li>A valid static document acted upon by the DOM will deliver a
consistent reproducible document structure.</li>
</ol>
</div>
<!-- div2 DocumentManipulation -->
<div class='div2'><a name=
'dom-level-1-requirements-ContentManipulation' id=
"dom-level-1-requirements-ContentManipulation"></a>
<h2 id='dom-level-1-requirements-ContentManipulation-h2' class=
'div2'>2.3 Content Manipulation</h2>
<ol>
<li>There will be a way to determine the containing element from
any text part of the document.</li>
<li>There will be a way to manipulate (add, change, delete)
content.</li>
<li>There will be a way to navigate content.</li>
</ol>
</div>
<!-- div2 ContentManipulation --></div>
<!-- div1 Level1 -->
<a id='dom-level-2-requirements' name=
'dom-level-2-requirements'></a>
<div class='div1'><a name='dom-level-2-requirements-Level2' id=
"dom-level-2-requirements-Level2"></a>
<h1 id='dom-level-2-requirements-Level2-h1' class='div1'>3. DOM
Level 2 Requirements</h1>
<div class='div2'><a name=
'dom-level-2-requirements-level2-eventmodel' id=
"dom-level-2-requirements-level2-eventmodel"></a>
<h2 id='dom-level-2-requirements-level2-eventmodel-h2' class=
'div2'>3.1 Event Model</h2>
<p>The event model must be rich enough to create completely
interactive documents. This requires the ability to respond to any
user action that may occur on the document. Therefore, many of
these requirements only apply if a UI component is involved.</p>
<ol>
<li>All elements will be capable of generating events.</li>
<li>There will be user interface events, mutation events, and
logical events.</li>
<li>The event delivery mechanism will allow for overriding of
default behavior.</li>
<li>The event model will provide a mechanism by which events for
specific elements may be received by an ancestor in the DOM
hierarchy.</li>
<li>Events may be synchronous.</li>
<li>Events will be defined in a platform independent and language
neutral way.</li>
<li>There will be an interface for binding to events.</li>
</ol>
</div>
<!-- div2 level2-eventmodel -->
<div class='div2'><a name=
'dom-level-2-requirements-level2-stylesheet' id=
"dom-level-2-requirements-level2-stylesheet"></a>
<h2 id='dom-level-2-requirements-level2-stylesheet-h2' class=
'div2'>3.2 Stylesheet Object Model</h2>
<p>Cascading Style Sheets (CSS) is one model for manipulating the
style of the document. The Stylesheet Object Model exposes the
ability to create, modify, and associate CSS style sheets with the
document. The stylesheet model will be extensible to other
stylesheet formats in the future.</p>
<ol>
<li>All style sheets will be represented in the object model.</li>
<li>There will be a CSS stylesheet model. The CSS object model will
be defined as part of a stylesheet embedding model, where the core
part of the model may be applicable to other style languages.</li>
<li>Selectors, rules and properties of individual style sheets can
be added, removed and changed.</li>
<li>All elements of a CSS style can be added, removed, and changed
in the object model. This includes but is not limited to:
<ol>
<li>linked style sheets</li>
<li>imported style sheets</li>
<li>alternative style sheets</li>
<li>CSS pseudo-classes and CSS pseudo-elements</li>
<li>contextual selectors</li>
<li>inline styles</li>
<li>all properties as defined in the CSS specification, including
but not limited to font properties, colors, backgrounds, and box
properties.</li>
</ol>
</li>
</ol>
</div>
<!-- div2 level2-stylesheet -->
<div class='div2'><a name='dom-level-2-requirements-level2-range'
id="dom-level-2-requirements-level2-range"></a>
<h2 id='dom-level-2-requirements-level2-range-h2' class='div2'>3.3
Range model</h2>
<dl>
<dt>Linear view</dt>
<dd>allows querying and editing functionality based on a range of
text rather than a subtree of Nodes.</dd>
<dt>Live</dt>
<dd>edits on the range modify the underlying tree</dd>
<dt>Low Level</dt>
<dd>no parser, no relationship to user agent, no convenience
methods or range comparison methods (these would be part of the
SmartRange interface)</dd>
</dl>
<p>The DOM Range API should support the following types of
operations on ranges:</p>
<ul>
<li>Creating a Range object</li>
<li>Extracting text from a Range (with or without markup)</li>
<li>Inserting, Deleting text inside the Range</li>
<li>Inserting, Deleting document structure inside the Range</li>
</ul>
</div>
<!-- div2 level2-range -->
<div class='div2'><a name=
'dom-level-2-requirements-level2-traversal' id=
"dom-level-2-requirements-level2-traversal"></a>
<h2 id='dom-level-2-requirements-level2-traversal-h2' class='div2'>
3.4 Traversal model</h2>
<p>The DOM Traversal API should be able to see a filtered view
without comments or entity references, and to have an iterator
robust under mutation.</p>
</div>
<!-- div2 level2-traversal --></div>
<!-- div1 Level2 -->
<a id='dom-level-3-requirements' name=
'dom-level-3-requirements'></a>
<div class='div1'><a name='dom-level-3-requirements-Level3' id=
"dom-level-3-requirements-Level3"></a>
<h1 id='dom-level-3-requirements-Level3-h1' class='div1'>4. DOM
Level 3 Requirements</h1>
<div class='div2'><a name='dom-level-3-requirements-level3-core'
id="dom-level-3-requirements-level3-core"></a>
<h2 id='dom-level-3-requirements-level3-core-h2' class='div2'>4.1
Core Requirements</h2>
<p>Here are the items that will be addressed:</p>
<ul>
<li>getting the text content as a single DOMString from a section
of a document.</li>
<li>moving (not copying!) a node from one document to another. DOM
Level 2 provides an importNode method that copies a node from one
document to another, it would be useful to have a way of simply
moving a node, even though in some cases, such as across
implementations, it may fail.</li>
<li>node ordering. Is this node before that one in document order?
Although this can be done on top of the DOM Level 2, having it as
part of the DOM would provide for possible optimisations.</li>
<li>whitespace in element content (a.k.a. "ignorable whitespace").
Does this Text node only contain whitespace in element
content?</li>
<li>exposing the XML and Text declarations.</li>
<li>exposing the base URI of a node (part of the XML Infoset)</li>
<li>node identity. Is this object the same node as that one?</li>
<li>namespace lookup. DOM Level 2 is based on an early binding
model and the implementation does not provide any lookup
mechanism.</li>
<li>namespace fixup. DOM Level 2 is based on an early binding model
and the implementation does not fix the namespace declarations as
nodes are moved around or inserted.</li>
<li>bootstrapping a DOM in Java. How does one get a hand on a
DOMImplementation class?</li>
<li>provide for readonly DOMs.</li>
<li>allow methods to raise other exceptions. So that for instance
insertBefore can fail because of a DTD pb.</li>
</ul>
<p>Here are other items that will be considered:</p>
<ul>
<li>a way to turn off error checking, so that better performance
can be achieved, such as when the DOM is built from a parser which
already performs error checking.</li>
<li>a way to attach some user data to a node.</li>
<li>node equality and hashcode</li>
<li>getElementsByAttributeValue.</li>
<li>a way to allow text documents</li>
</ul>
</div>
<!-- div2 level3-core -->
<div class='div2'><a name=
'dom-level-3-requirements-Level-3-Events-Requirements' id=
"dom-level-3-requirements-Level-3-Events-Requirements"></a>
<h2 id='dom-level-3-requirements-Level-3-Events-Requirements-h2'
class='div2'>4.2 Level 3 Events Requirements</h2>
<p>The DOM Level 3 Events specification will attempt to address
some of the remaining issues from the DOM Level 2 Event
specification as well as a couple or requested enhancements to the
model. It will not attempt to redesign the model nor will attempt
to define any additional event models.</p>
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-Events-Requirements-eventGrouping'
   id=
   "dom-level-3-requirements-Level-3-Events-Requirements-eventGrouping">
</a>
<h3 id=
'dom-level-3-requirements-Level-3-Events-Requirements-eventGrouping-h3'
    class='div3'>4.2.1 EventListener grouping</h3>
<p>The specification must define a technique for registering
<code>EventListener</code>s in groups. These groups will then have
specified behavior in which attempts to modify the flow of an event
will be restricted and affected only the group to which the
<code>EventListener</code> in question belongs.</p>
<p>It is also required that whatever technique is specified to
accomplish this purpose be compatible with the existing DOM Level 2
Event model and any <code>EventListener</code>s registered using
DOM Level 2 Event model methods.</p>
</div>
<!-- div3 Level-3-Events-Requirements-eventGrouping -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-Events-Requirements-keyEvents'
id="dom-level-3-requirements-Level-3-Events-Requirements-keyEvents">
</a>
<h3 id=
'dom-level-3-requirements-Level-3-Events-Requirements-keyEvents-h3'
class='div3'>4.2.2 Key event set</h3>
<p>The specification must define a set of key events to handle
keyboard input. This key event set must be fully
internationalizable. It is hoped that this key event set will be
compatible with existing key event sets used in current systems
however this is not a requirement.</p>
</div>
<!-- div3 Level-3-Events-Requirements-keyEvents -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-Events-Requirements-inputEvent'
id=
"dom-level-3-requirements-Level-3-Events-Requirements-inputEvent"></a>
<h3 id=
'dom-level-3-requirements-Level-3-Events-Requirements-inputEvent-h3'
    class='div3'>4.2.3 Input event set</h3>
<p>The specification should attempt to define a set of input events
to handle IME based keyboard input. It is expected that this
requirement will depend heavily on any key event set defined by the
specification.</p>
</div>
<!-- div3 Level-3-Events-Requirements-inputEvent -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-Events-Requirements-deviceIndependent'
   id=
   "dom-level-3-requirements-Level-3-Events-Requirements-deviceIndependent">
</a>
<h3 id=
'dom-level-3-requirements-Level-3-Events-Requirements-deviceIndependent-h3'
    class='div3'>4.2.4 Device independent event set</h3>
<p>The specification must define a device independent event set.
This event set should allow notification of typical user
interaction with a document without requiring the use of either
mouse events or key events.</p>
<div style='color: red'>(<i><b>ED:</b></i> The following
requirements come from the <a class='normative' href=
'http://www.w3.org/WAI/PF/Group/DOM/dom3-req.htm'>DOM 3
Requirements and View Use Cases</a> (member-only link) from the WAI-PF Working Group.
)</div>
<p>Each Document View must provide a Device Independent UI Event
Model.</p>
<p>The following events are not present in the DOM Level 2
specification. Those related to selection should be picked up when
a selection model is included:</p>
<dl>
<dt>gainselection</dt>
<dd>The gainselection event occurs when a node or part of it is
selected (unlike the HTML event select, it can be applied to any
element, not just HTML FORM controls). For each selected node a
gainselection event, which can be handled locally or through
bubbling by a root node selection handler, is generated.
<ul>
<li>Bubbles: Yes</li>
<li>Cancelable: No</li>
<li>Context Info: range</li>
</ul>
</dd>
<dt>loseselection</dt>
<dd>The loseselection event occurs when a node or part of it is
deselected, for example because the user selects something else.
<ul>
<li>Bubbles: Yes</li>
<li>Cancelable: No</li>
<li>Context Info: range</li>
</ul>
</dd>
<dt>key</dt>
<dd>Key input may not be keyboard specific.</dd>
<dt>pointermove</dt>
<dd>Input may be a stylus rather than a mouse</dd>
</dl>
</div>
<!-- div3 Level-3-Events-Requirements-deviceIndependent --></div>
<!-- div2 Level-3-Events-Requirements -->
<div class='div2'><a name='dom-level-3-requirements-level3-CM' id=
"dom-level-3-requirements-level3-CM"></a>
<h2 id='dom-level-3-requirements-level3-CM-h2' class='div2'>4.3
Content Models and Validation Use Cases and Requirements</h2>
<p>The content model referenced in these use cases/requirements is
an abstraction and does not refer to DTDs or XML Schemas or any
transformations between the two.</p>
<p>For the CM-editing and document-editing worlds, the following
use cases and requirements are common to both and could be labeled
as the "Validation and Other Common Functionality" section:</p>
<p>Use Cases:</p>
<ol>
<li>CU1. Modify an existing content model.</li>
<li>CU2. Associating a content model (external and/or internal)
with a document, or changing the current association.</li>
<li>CU3. Using the same external content model with several
documents, without having to reload it.</li>
<li>CU4. Create a new content model.</li>
</ol>
<p>Requirements:</p>
<ol>
<li>CR1. Validate against the content model.</li>
<li>CR2. Retrieve information from content model.</li>
<li>CR3. Load an existing content model, perhaps independently from
a document.</li>
<li>CR4. Being able to determine if a document has a content model
associated with it.</li>
<li>CR5. Create a new content model object.</li>
<li>CR6. Associate a CM with a document and make it the active
CM.</li>
</ol>
<p>Specific to the CM-editing world, the following are use cases
and requirements and could be labeled as the "CM-editing"
section:</p>
<p>Use Cases:</p>
<ol>
<li>CMU1. Clone/map all or parts of an existing content model to a
new or existing content model.</li>
<li>CMU2. Save a content model in a separate file. For example, a
DTD can be broken up into reusable pieces, which are then brought
in via entity references, these can then be saved in a separate
file.</li>
<li>CMU3. Partial content model checking. For example, only certain
portions of the content model need be validated.</li>
</ol>
<p>Requirements:</p>
<ol>
<li>CMR1. View and modify all parts of the content model.</li>
<li>CMR2. Validate the content model itself. For example, if an
element/attribute is inserted incorrectly into the content
model.</li>
<li>CMR3. Serialize the content model.</li>
<li>CMR4. Clone all or parts of an existing content model.</li>
<li>CMR5. Validate portions of the XML document against the content
model.</li>
</ol>
<p>Specific to the document-editing world, the following are use
cases and requirements and could be labeled as the
"Document-editing" section:</p>
<p>Use Cases:</p>
<ol>
<li>DU1. For editing documents with an associated content model,
provide the assistance necessary so that valid documents can be
modified and remain valid.</li>
<li>DU2. For editing documents with an associated content model,
provide the assistance necessary to transform an invalid document
into a valid one.</li>
</ol>
<p>Requirements:</p>
<ol>
<li>DR1. Being able to determine if the document is not
well-formed, and if not, be given enough assistance to locate the
error.</li>
<li>DR2. Being able to determine if the document is not namespace
well-formed, and if not, be given enough assistance to locate the
error.</li>
<li>DR3. Being able to determine if the document is not valid with
respect to its associated content model, and if not, give enough
assistance to locate the error.</li>
<li>DR4. Being able to determine if specific modifications to a
document would make it become invalid.</li>
<li>DR5. Retrieve information from all content model. For example,
getting a list of all the defined element names for document
editing purposes.</li>
</ol>
<p>General Issues:</p>
<ol>
<li>I1. Namespace issues associated with the content model. To
address namespaces, a <code>isNamespaceAware</code> attribute to
the generic CM object has been added to help applications determine
if qualified names are important. Note that this should not be
interpreted as helping identify what the underlying content model
is. A MathML example to show how namespaced documents will be
validated will be added later.</li>
<li>I2. Multiple CMs being associated with a XML document. For
validation, this could: 1) result in an exception; 2) a merged
content model for the document to be validated against; 3) each
content model for the document to be validated against separately.
In this chapter, we have gone for the third choice, allowing the
user to specify which content model to be active and allowing them
to keep adding content models to a list associated with the
document.</li>
<li>I3. Content model being able to handle more datatypes than
strings. Currently, this functionality is not available and should
be dealt with in the future.</li>
<li>I4. Round-trippability for include/ignore statements and other
constructs such as parameter entities, e.g., "macro-like"
constructs, will not be supported since no data representation
exists to support these constructs without having to re-parse
them.</li>
<li>I5. Basic interface for a common error handler both CM and
Load/Save. Agreement has been to utilize user-registered callbacks
but other details to be worked out.</li>
</ol>
</div>
<!-- div2 level3-CM -->
<div class='div2'><a name=
'dom-level-3-requirements-Level-3-LS-Requirements' id=
"dom-level-3-requirements-Level-3-LS-Requirements"></a>
<h2 id='dom-level-3-requirements-Level-3-LS-Requirements-h2' class=
'div2'>4.4 Load and Save Requirements</h2>
<p>DOM Level 3 will provide an API for loading XML source documents
into a DOM representation and for saving a DOM representation as a
XML document.</p>
<p>Some environments, such as the Java platform or COM, have their
own ways to persist objects to streams and to restore them. There
is no direct relationship between these mechanisms and the DOM
load/save mechanism. This specification defines how to serialize
documents only to and from XML format.</p>
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-LS-General-Requirements' id=
"dom-level-3-requirements-Level-3-LS-General-Requirements"></a>
<h3 id=
'dom-level-3-requirements-Level-3-LS-General-Requirements-h3'
class='div3'>4.4.1 General Requirements</h3>
<p>Requirements that apply to both loading and saving
documents.</p>
<div class='div4'><a name='dom-level-3-requirements-s-4.4.1.1' id=
"dom-level-3-requirements-s-4.4.1.1"></a>
<h4 id='dom-level-3-requirements-s-4.4.1.1-h4' class='div4'>4.4.1.1
Document Sources</h4>
<p>Documents must be able to be parsed from and saved to the
following sources:</p>
<ul>
<li>Input and Output Streams</li>
<li>URIs</li>
<li>Files</li>
</ul>
<p>Note that Input and Output streams take care of the in memory
case. One point of caution is that a stream doesn't allow a base
URI to be defined against which all relative URIs in the document
are resolved.</p>
</div>
<!-- div4 s-4.4.1.1 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.1.2' id=
"dom-level-3-requirements-s-4.4.1.2"></a>
<h4 id='dom-level-3-requirements-s-4.4.1.2-h4' class='div4'>4.4.1.2
Content Model Loading</h4>
<p>While creating a new document using the DOM API, a mechanism
must be provided to specify that the new document uses a
pre-existing Content Model and to cause that Content Model to be
loaded.</p>
<p>Note that while DOM Level 2 creation can specify a Content Model
when creating a document (public and system IDs for the external
subset, and a string for the subset), DOM Level 2 implementations
do not process the Content Model's content. For DOM Level 3, the
Content Model's content must be read.</p>
</div>
<!-- div4 s-4.4.1.2 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.1.3' id=
"dom-level-3-requirements-s-4.4.1.3"></a>
<h4 id='dom-level-3-requirements-s-4.4.1.3-h4' class='div4'>4.4.1.3
Content Model Reuse</h4>
<p>When processing a series of documents, all of which use the same
Content Model, implementations should be able to reuse the already
parsed and loaded Content Model rather than reparsing it again for
each new document.</p>
<p>This feature may not have an explicit DOM API associated with
it, but it does require that nothing in this section, or the
Content Model section, of this specification block it or make it
difficult to implement.</p>
</div>
<!-- div4 s-4.4.1.3 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.1.4' id=
"dom-level-3-requirements-s-4.4.1.4"></a>
<h4 id='dom-level-3-requirements-s-4.4.1.4-h4' class='div4'>4.4.1.4
Entity Resolution</h4>
<p>Some means is required to allow applications to map public and
system IDs to the correct document. This facility should provide
sufficient capability to allow the implementation of catalogs, but
providing catalogs themselves is not a requirement. In addition XML
Base needs to be addressed.</p>
</div>
<!-- div4 s-4.4.1.4 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.1.5' id=
"dom-level-3-requirements-s-4.4.1.5"></a>
<h4 id='dom-level-3-requirements-s-4.4.1.5-h4' class='div4'>4.4.1.5
Error Reporting</h4>
<p>Loading a document can cause the generation of errors
including:</p>
<ul>
<li>I/O Errors, such as the inability to find or open the specified
document.<br />
XML well formedness errors.<br />
Validity errors</li>
</ul>
<p>Saving a document can cause the generation of errors
including:</p>
<ul>
<li>I/O Errors, such as the inability to write to a specified
stream, URL, or file.<br />
Improper constructs, such as '--' in comments, in the DOM that
cannot be represented as well formed XML.</li>
</ul>
<p>This section, as well as the DOM Level 3 Content Model section
should use a common error reporting mechanism. Well-formedness and
validity checking are in the domain of the Content Model section,
even though they may be commonly generated in response to an
application asking that a document be loaded.</p>
</div>
<!-- div4 s-4.4.1.5 --></div>
<!-- div3 Level-3-LS-General-Requirements -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-LS-Load-Requirements' id=
"dom-level-3-requirements-Level-3-LS-Load-Requirements"></a>
<h3 id='dom-level-3-requirements-Level-3-LS-Load-Requirements-h3'
class='div3'>4.4.2 Load Requirements</h3>
<p>The following requirements apply to loading documents.</p>
<div class='div4'><a name='dom-level-3-requirements-s-4.4.2.1' id=
"dom-level-3-requirements-s-4.4.2.1"></a>
<h4 id='dom-level-3-requirements-s-4.4.2.1-h4' class='div4'>4.4.2.1
Parser Properties and Options</h4>
<p>Parsers may have properties or options that can be set by
applications. Examples include:</p>
<ul>
<li>Expansion of entity references.</li>
<li>Creation of entity ref nodes.</li>
<li>Handling of white space in element content.</li>
<li>Enabling of namespace handling.</li>
<li>Enabling of content model validation.</li>
</ul>
<p>A mechanism to set properties, query the state of properties,
and to query the set of properties supported by a particular DOM
implementation is required.</p>
</div>
<!-- div4 s-4.4.2.1 --></div>
<!-- div3 Level-3-LS-Load-Requirements -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-LS-XML-Writer-Requirments' id=
"dom-level-3-requirements-Level-3-LS-XML-Writer-Requirments"></a>
<h3 id=
'dom-level-3-requirements-Level-3-LS-XML-Writer-Requirments-h3'
class='div3'>4.4.3 XML Writer Requirements</h3>
<p>The fundamental requirement is to write a DOM document as XML
source. All information to be serialized should be available via
the normal DOM API.</p>
<div class='div4'><a name='dom-level-3-requirements-s-4.4.3.1' id=
"dom-level-3-requirements-s-4.4.3.1"></a>
<h4 id='dom-level-3-requirements-s-4.4.3.1-h4' class='div4'>4.4.3.1
XML Writer Properties and Options</h4>
<p>There are several options that can be defined when saving an XML
document. Some of these are:</p>
<ul>
<li>Saving to Canonical XML format.</li>
<li>Pretty Printing.</li>
<li>Specify the encoding in which a document is written.</li>
<li>How and when to use character entities.</li>
<li>Namespace prefix handling.</li>
<li>Saving of Content Models.</li>
<li>Handling of external entities.</li>
</ul>
</div>
<!-- div4 s-4.4.3.1 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.3.2' id=
"dom-level-3-requirements-s-4.4.3.2"></a>
<h4 id='dom-level-3-requirements-s-4.4.3.2-h4' class='div4'>4.4.3.2
Content Model Saving</h4>
<p>Requirement from the Content Model group.</p>
</div>
<!-- div4 s-4.4.3.2 --></div>
<!-- div3 Level-3-LS-XML-Writer-Requirments -->
<div class='div3'><a name=
'dom-level-3-requirements-Level-3-LS-Other-Requirements' id=
"dom-level-3-requirements-Level-3-LS-Other-Requirements"></a>
<h3 id='dom-level-3-requirements-Level-3-LS-Other-Requirements-h3'
class='div3'>4.4.4 Other Items Under Consideration</h3>
<p>The following items are not committed to, but are under
consideration. Public feedback on these items is especially
requested.</p>
<div class='div4'><a name='dom-level-3-requirements-s-4.4.4.1' id=
"dom-level-3-requirements-s-4.4.4.1"></a>
<h4 id='dom-level-3-requirements-s-4.4.4.1-h4' class='div4'>4.4.4.1
Incremental and/or Concurrent Parsing</h4>
<p>Provide the ability for a thread that requested the loading of a
document to continue execution without blocking while the document
is being loaded. This would require some sort of notification or
completion event when the loading process was done.</p>
<p>Provide the ability to examine the partial DOM representation
before it has been fully loaded.</p>
<p>In one form, a document may be loaded asynchronously while a DOM
based application is accessing the document. In another form, the
application may explicitly ask for the next incremental portion of
a document to be loaded.</p>
</div>
<!-- div4 s-4.4.4.1 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.4.2' id=
"dom-level-3-requirements-s-4.4.4.2"></a>
<h4 id='dom-level-3-requirements-s-4.4.4.2-h4' class='div4'>4.4.4.2
Filtered Save</h4>
<p>Provide the capability to write out only a part of a document.
May be able to leverage TreeWalkers, or the Filters associated with
TreeWalkers, or Ranges as a means of specifying the portion of the
document to be written.</p>
</div>
<!-- div4 s-4.4.4.2 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.4.3' id=
"dom-level-3-requirements-s-4.4.4.3"></a>
<h4 id='dom-level-3-requirements-s-4.4.4.3-h4' class='div4'>4.4.4.3
Document Fragments</h4>
<p>Document fragments, as specified by the XML Fragment
specification, should be able to be loaded. This is useful to
applications that only need to process some part of a large
document. Because the DOM is typically implemented as an in-memory
representation of a document, fully loading large documents can
require large amounts of memory.</p>
<p>XPath should also be considered as a way to identify XML
Document fragments to load.</p>
</div>
<!-- div4 s-4.4.4.3 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.4.4.4' id=
"dom-level-3-requirements-s-4.4.4.4"></a>
<h4 id='dom-level-3-requirements-s-4.4.4.4-h4' class='div4'>4.4.4.4
Document Fragments in Context of Existing DOM</h4>
<p>Document fragments, as specified by the XML Fragment
specification, should be able to be loaded into the context of an
existing document at a point specified by a node position, or
perhaps a range. This is a separate feature than simply loading
document fragments as a new Node.</p>
</div>
<!-- div4 s-4.4.4.4 --></div>
<!-- div3 Level-3-LS-Other-Requirements --></div>
<!-- div2 Level-3-LS-Requirements -->
<div class='div2'><a name=
'dom-level-3-requirements-Level-3-Embedded' id=
"dom-level-3-requirements-Level-3-Embedded"></a>
<h2 id='dom-level-3-requirements-Level-3-Embedded-h2' class='div2'>
4.5 Embedded DOM Requirements</h2>
<div class='div3'><a name='dom-level-3-requirements-EDOM-Abstract'
id="dom-level-3-requirements-EDOM-Abstract"></a>
<h3 id='dom-level-3-requirements-EDOM-Abstract-h3' class='div3'>
4.5.1 Abstract</h3>
<p>This document discusses the requirements and framework for using
multiple implementations of DOM or DOM-based APIs designed for a
particular markup language within a single standard DOM
application. Up until now, the Document Object Model design has
been concerned with defining an API to an entire XML document,
where all methods and attributes in the API apply equally to the
entire document and it is assumed that only one implementation of
the DOM is needed by an application.</p>
<p>With the advent of markup languages such as <a class='normative'
href='http://www.w3.org/TR/SVG'>Scalable Vector Graphics</a> and
the <a class='normative' href=
'http://www.w3.org/TR/MathML2'>Mathematical Markup Language</a>, it
has become obvious that this simple model no longer applies. It is
quite possible to have documents which embed some MathML or SVG
markup, where a DOM application might reasonably expect to be able
to use the specialized MathML or SVG DOM-based APIs. Similarly,
many DOM applications are being designed to "glue" together two
systems that both implement the DOM, and need some standard
mechanism to assist in making the multiple implementations
interoperate.</p>
<p>A module of Level 3 DOM, which we shall refer to by the
shorthand name "EDOM", will address this issue.</p>
</div>
<!-- div3 EDOM-Abstract -->
<div class='div3'><a name=
'dom-level-3-requirements-EDOM-Introduction' id=
"dom-level-3-requirements-EDOM-Introduction"></a>
<h3 id='dom-level-3-requirements-EDOM-Introduction-h3' class=
'div3'>4.5.2 Introduction</h3>
<p>As new XML vocabularies are developed, those defining the
vocabularies are beginning to define specialized APIs for
manipulating XML instances of those vocabularies by extending the
DOM to provide interfaces and methods that perform operations
frequently needed their users. For example, the MathML and SVG
groups are developing DOM extensions to allow users to manipulate
instances of these vocabularies using semantics appropriate to
images and mathematics (respectively) as well as the generic DOM
"tree" semantics. Instances of SVG or MathML are often embedded in
XML documents conforming to a different schema such as XHTML or
DocBook. While the XML Namespaces Recommendation provides a
mechanism for integrating these documents at the syntax level, it
has become clear that the DOM Level 2 Recommendation is not rich
enough to cover all the issues that have been encountered in having
these different DOM implementations be used together in a single
application. The Embedded DOM module deals with the requirements
brought about by embedding fragments written according to a
specific markup language (the <em>embedded</em> component) in a
document where the rest of the markup is not written according to
that specific markup language (the <em>host</em> document). It does
not deal with fragments embedded by reference or linking.</p>
<p>We are seeing at least two implementation scenarios in which DOM
components can be embedded in a host DOM. One extreme might be
called the "monolithic" scenario in which a single product (e.g.
the Mozilla browser) implements both the generic host DOM and the
specialized embedded DOM. The embedded DOM still has a different
<code>DOMImplementation</code> object than the host because it will
support a different feature set, although it is quite likely that
the embedded and host DOMs will use compatible classes or data
structures. At the other extreme, the embedded DOM reflects a
completely different implementation, perhaps from an entirely
different vendor, e.g. an Adobe SVG component plugged into the
SoftQuad editor.</p>
<p>The general objective of the EDOM ET is to define whatever
mechanisms are required in order to make documents that are
actually handled by two or more DOM implementations work together
as seamlessly and compatibly as possible under various
implementation scenarios. Ideally, a DOM application writer should
see the entire document as a coherent unit, with certain Nodes that
are actually handled by embedded DOMs simply having more
specialized capabilities. It is not clear at this point whether
this is achievable for all scenarios, but our goal is to make it
seamless for applications that do not care about the differences,
and to make it possible for applications that do care about the
differences to discover which DOM handles embedded nodes, be
informed of where the boundaries are, and to use that
implementation to its fullest extent.</p>
<p>Achieving these objective may entail clarifications to the
wording of the DOM specification, new interfaces or methods on
existing interfaces, revised requirements for the Load/Save module
so that the multiple DOMs are built and linked together at parse
time, or some combination of these.</p>
</div>
<!-- div3 EDOM-Introduction -->
<div class='div3'><a name='dom-level-3-requirements-EDOM-UseCases'
id="dom-level-3-requirements-EDOM-UseCases"></a>
<h3 id='dom-level-3-requirements-EDOM-UseCases-h3' class='div3'>
4.5.3 Use Cases</h3>
<p>We will consider the following use cases when assessing proposed
requirements and in designing the DOM extensions to support
embedded DOMs. All assume that some DOM Level 3 methods have been
called to link the various DOM implementations together so that DOM
boundaries can be detected and handled.</p>
<div class='div4'><a name='dom-level-3-requirements-s-4.5.3.1' id=
"dom-level-3-requirements-s-4.5.3.1"></a>
<h4 id='dom-level-3-requirements-s-4.5.3.1-h4' class='div4'>4.5.3.1
Navigation from host to embedded DOM</h4>
<p>A DOM application running on the host DOM implementation may
need to access information controlled by the embedded DOM, e.g. to
serialize the entire document.</p>
</div>
<!-- div4 s-4.5.3.1 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.5.3.2' id=
"dom-level-3-requirements-s-4.5.3.2"></a>
<h4 id='dom-level-3-requirements-s-4.5.3.2-h4' class='div4'>4.5.3.2
Navigation from embedded DOM to host</h4>
<p>A DOM application running on the embedded DOM implementation may
need to access information controlled by the host DOM, e.g. to
query a style attribute, namespace declaration, etc.</p>
</div>
<!-- div4 s-4.5.3.2 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.5.3.3' id=
"dom-level-3-requirements-s-4.5.3.3"></a>
<h4 id='dom-level-3-requirements-s-4.5.3.3-h4' class='div4'>4.5.3.3
Event capture and bubbling across Host DOM/Embedded DOM
boundary</h4>
<p>A DOM application may need to detect and process events
irrespective of whether they occur in a host or embedded DOM.</p>
</div>
<!-- div4 s-4.5.3.3 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.5.3.4' id=
"dom-level-3-requirements-s-4.5.3.4"></a>
<h4 id='dom-level-3-requirements-s-4.5.3.4-h4' class='div4'>4.5.3.4
Seamless view of host, embedded DOMs</h4>
<p>It may be acceptable for DOM Level 3 applications to use
additional APIs to detect host/embedded DOM boundaries and to
navigate across them. Nevertheless, it would be far better for
users if ordinary node navigation operations, validation,
iterators/treewalkers, and event propagation worked seamlessly
across DOM boundaries.</p>
</div>
<!-- div4 s-4.5.3.4 -->
<div class='div4'><a name='dom-level-3-requirements-s-4.5.3.5' id=
"dom-level-3-requirements-s-4.5.3.5"></a>
<h4 id='dom-level-3-requirements-s-4.5.3.5-h4' class='div4'>4.5.3.5
Notification of document changes across Host/Embedded boundary</h4>
<p>A DOM application may need to be aware of changes to the
document tree irrespective of whether they were initiated in a host
or embedded DOM.</p>
</div>
<!-- div4 s-4.5.3.5 --></div>
<!-- div3 EDOM-UseCases -->
<div class='div3'><a name='dom-level-3-requirements-EDOM-Scenarios'
id="dom-level-3-requirements-EDOM-Scenarios"></a>
<h3 id='dom-level-3-requirements-EDOM-Scenarios-h3' class='div3'>
4.5.4 Implementation Scenarios</h3>
<p>We have prepared the following grid to clarify the different
scenarios under which a standard for defining how an embedded DOM
interoperates with a host DOM could be implemented, and what this
means for the application programmer using the DOM interfaces.</p>
<p>One axis of the grid reflects the different architectures in
which one DOM can be imbedded in another. The alternatives we are
considering include:</p>
<ul>
<li>Monolithic - The host DOM and the embedded DOM are implemented
by the same code. The host/embedded distinction exists mainly to
reflect the different features of nodes at different levels.
Examples of this would appear to include Mozilla's support for
MathML and SVG, IE5's support for VML, and Amaya's support for
MathML.</li>
<li>Dynamic Subclass - Some proprietary mechanism such as Microsoft
"binary behaviors" or Netscape's XBL is used to construct embedded
DOM subtrees trees that appear to be subclasses (for DOM purposes)
of the host DOM nodes. In a Java environment, a user could
dynamically subclass another implementation.</li>
<li>Wrapper - The host and embedded DOMs are completely separate
implementations that are woven together to provide support for a
different subtrees of a single document. Since there is no
subclassing mechanism to redirect implementation-level methods to
the proper code, we envision "wrapper" classes that could implement
the EDOM functionality by redirecting operations on "foreign" nodes
to the standard DOM interfaces rather than the implementation
classes.</li>
</ul>
<ul>
<li>Data Island - Two DOM implementations that are really separate
documents, conceptually different and having no hierarchical
relationship that can be inferred. An example would be a Microsoft
XML data island inside an HTML document. <em>This is essentially a
non-use case, presented simply to identify it and contrast it with
scenarios that we do envision supporting.</em></li>
</ul>
<p>The other axis reflects the properties or features of the DOM
API that could be preserved across the host / embedded border. The
features under consideration include:</p>
<ul>
<li>Awareness - Can the user query the host DOM about the identity
and location of embedded DOMs? This implies that there is some way
to get an opaque handle that the DOM doesn't know what to do with,
but the application programmer may, at the boundary between a host
DOM and embedded DOM.</li>
<li>Boundary-aware navigation - Is it possible -- perhaps by
calling a new API method -- for an application programmer to
navigate from a host DOM node into an embedded DOM node, and from
an embedded DOM node into the host DOM that embeds it? In other
words, there is a "semi-permeable barrier" between the host and
embedded DOMs and an API with which to cross it.</li>
<li>Seamlessness- Can an application programmer navigate across the
host/embedded boundary without being aware it exists? Do properties
such as IDs, unique identifiers, timings, etc. appear to work
seamlessly across embedded DOM boundaries?</li>
<li>Event propagation - Do DOM events bubble and be captured across
embedded DOM boundaries?</li>
<li>CSS Inheritance- Do CSS properties on the host DOM pass down to
the embedded DOM?</li>
</ul>
<p>The Embedded DOM plans to support the following use cases
derived from this grid:</p>
<table border='1'>
<tr>
<td bgcolor='#CFCFCF' rowspan='1' colspan='1'></td>
<td bgcolor='#CFCFCF' rowspan='1' colspan='1'>
<b>Monolithic</b></td>
<td bgcolor='#CFCFCF' rowspan='1' colspan='1'><b>Dynamic</b></td>
<td bgcolor='#CFCFCF' rowspan='1' colspan='1'><b>Wrappers</b></td>
<td bgcolor='#CFCFCF' rowspan='1' colspan='1'><b>Data
Island</b></td>
</tr>
<tr>
<td valign='top' rowspan='1' colspan='1'>Awareness</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
</tr>
<tr>
<td valign='top' rowspan='1' colspan='1'>Boundary Navigation</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
</tr>
<tr>
<td valign='top' rowspan='1' colspan='1'>Seamlessness</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
<td valign='top' rowspan='1' colspan='1'>No</td>
</tr>
<tr>
<td valign='top' rowspan='1' colspan='1'>Event Propagation</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Yes</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
<td valign='top' rowspan='1' colspan='1'>No</td>
</tr>
<tr>
<td valign='top' rowspan='1' colspan='1'>CSS Inheritance</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
<td valign='top' rowspan='1' colspan='1'>Maybe</td>
<td valign='top' rowspan='1' colspan='1'>No</td>
</tr>
</table>
</div>
<!-- div3 EDOM-Scenarios -->
<div class='div3'><a name=
'dom-level-3-requirements-EDOM-Requirements' id=
"dom-level-3-requirements-EDOM-Requirements"></a>
<h3 id='dom-level-3-requirements-EDOM-Requirements-h3' class=
'div3'>4.5.5 Requirements</h3>
<ol>
<li>The EDOM MUST specify an object model that describes the
relationship between host DOM nodes and embedded DOM nodes, as well
as an API or other mechanism with which those relationships can be
specified. This object model MUST co-exist gracefully with the DOM
Level 3 Content Model interfaces and work with validation
operations.<br />
The EDOM MAY specify a mechanism -- such as options in the
Load/Save interfaces -- so that the association between Elements
and embedded DOMs is automatically produced when a document is
loaded.<br />
The EDOM NEED NOT specify the actual mechanism by which the
application actually loads a plug-in.</li>
<li>The EDOM MUST clarify the relationship between the
ownerDocument property of Nodes in an embedded DOM, the top-level
node in an Embedded DOM, and the Document interface. The standard
DOM object model and API may need to accommodate or even preclude
the situation in which elements inside some embedded markup may
have a different "owner document" and "dom implementation" values
than those at another level of the hierarchy. So far the DOM WG has
recommended that there only ever be one ownerDocument, which is the
same for all nodes.</li>
<li>For the "monolithic" and "dynamic subclassing" implementation
scenarios, the EDOM MUST specify a mechanism so that an embedded
DOM and a host DOM become aware of each other and support all of
the use cases described above.</li>
<li>For the "wrapper" implementation scenario, the EDOM MUST
specify a mechanism so that an embedded DOM and a host DOM become
aware of each other and that the boundary between them can be
crossed by an application. It would be desirable for this boundary
crossing to be "seamless", and for events and CSS properties to
propagate automatically across the boundary.</li>
</ol>
</div>
<!-- div3 EDOM-Requirements -->
<div class='div3'><a name=
'dom-level-3-requirements-EDOM-knownQuestions' id=
"dom-level-3-requirements-EDOM-knownQuestions"></a>
<h3 id='dom-level-3-requirements-EDOM-knownQuestions-h3' class=
'div3'>4.5.6 Known Questions</h3>
<p>Ranges are probably out of scope for the EDOM, anyone
disagree?</p>
<p>Do we want to support both a procedural mechanism and a
non-procedural mechanism (something like the HTML &lt;object&gt;
tag) to specify the relationship between the host and embedded
DOM?</p>
<div style='color: red'>(<i><b>ED:</b></i> The rest of this section
is a bit of a grab bag for ideas we will have to consider when it
comes time to work on the actual specification that meets these
requirements. )</div>
<p>Do we have two DOM trees, one for the generic DOM, and one for
the specialized DOM? (The sentiment at the Redwood Shores F2F was
"no").</p>
<p>How do you know when to hand control over to embedded DOM? Does
getChildNodes() and getParentNode() throw a new exception?</p>
<p>What sort of node should the top-level embedded node be? If it
is a special node that is a "document" in some sense but a child of
another in other senses, that would help. But it does need to be an
element rather than a document, so that the ownerDocument is
consistent throughout the complete document, including the embedded
fragment.</p>
<p>How do you get a handle to a DOMImplementation object without a
Document object ... we may need to solve the bootstrapping
problem.</p>
<p>The embedded DOM API needs to add something like a
createMyTopLevelElement from a Core DOM element, or maybe from a
string. The string method, while not as elegant, is more likely to
work across different languages and platforms.</p>
<p>What happens if a node from the embedded DOM tree is moved
outside the embedded DOM tree? Is this possible?</p>
<p>What about recursive embedded DOMs? Including the case where
XHTML is within SVG is within XHTML.</p>
</div>
<!-- div3 EDOM-knownQuestions --></div>
<!-- div2 Level-3-Embedded -->
<div class='div2'><a name='dom-level-3-requirements-level3-xpath'
id="dom-level-3-requirements-level3-xpath"></a>
<h2 id='dom-level-3-requirements-level3-xpath-h2' class='div2'>4.6
XPath DOM Draft Requirements</h2>
<div class='div3'><a name='dom-level-3-requirements-xpath-abstract'
id="dom-level-3-requirements-xpath-abstract"></a>
<h3 id='dom-level-3-requirements-xpath-abstract-h3' class='div3'>
4.6.1 Abstract</h3>
<p>There is a widely-perceived need to offer a vendor-neutral way
to use XPath expressions to select matching nodes in a DOM
document. A module of DOM, which we shall refer to by the shorthand
name "XPATH", will address this issue.</p>
</div>
<!-- div3 xpath-abstract -->
<div class='div3'><a name=
'dom-level-3-requirements-xpath-introduction' id=
"dom-level-3-requirements-xpath-introduction"></a>
<h3 id='dom-level-3-requirements-xpath-introduction-h3' class=
'div3'>4.6.2 Introduction</h3>
<p>Levels 1 and 2 of the DOM has some functionality to allow
specific nodes to be located without the user having to navigate
through the DOM tree, notably <code>getElementsByTagName</code> and
<code>getElementById</code>. The Working Group's intention was to
add these very limited APIs as a stop-gap until an XML-aware
"query" language was available. While not by any means a complete
XML query language, <a class='normative' href=
'http://lists.w3.org/Archives/Public/www-dom-xpath/'><em>XPath</em></a>
does provide a syntax for locating XML content by value and has
been a W3C Recommendation since November, 1999. Various DOM
implementations support APIs that allow one or more nodes to be
located via an XPath expression, and there have been a number of
calls from the user community to incorporate this capability into
the DOM Level 3 Recommendation.</p>
<p>A semi-public mailing list was established in early 2000 to
solicit input and advice (the <a class='normative' href=
'http://lists.w3.org/Archives/Public/www-dom-xpath/'>archives</a>
can be viewed at
http://lists.w3.org/Archives/Public/www-dom-xpath). The comments on
this list tended to push for a quite complete XPath API rather than
the quite limited interfaces provided by existing DOM
implementations. Since this is out of scope for the DOM WG, efforts
were made to find another W3C Working Group to take on this
requirement. Those efforts have not been successful.</p>
<p>Thus, it falls to the DOM WG to define a simple but effective
API for DOM that provides a basis for writing interoperable DOM
applications that use XPath expressions rather than tree navigation
to locate nodes matching simple search criteria.</p>
</div>
<!-- div3 xpath-introduction -->
<div class='div3'><a name=
'dom-level-3-requirements-xpath-requirements' id=
"dom-level-3-requirements-xpath-requirements"></a>
<h3 id='dom-level-3-requirements-xpath-requirements-h3' class=
'div3'>4.6.3 Requirements</h3>
<ol>
<li>The DOM XPATH module MUST provide one or more methods to allow
a set of nodes matching an XPath expression to be identified.</li>
<li>The DOM XPATH module MUST provide a mechanism so that the
namespace context of the XPath expression can be specified, that
is, so that any namespace prefixes in the XPath expression can be
resolved.</li>
<li>The DOM XPATH module MUST use the same data model as XPath
itself. There are some subtle differences between the XPath data
model and the DOM data model (e.g., the ownerDocument vs parentNode
property to describe the Element containing an Attribute, the
absence of CDATA marked sections in the XPath model, etc.). Since a
combined XPath/XSLT/XQuery data model will be defined in the XPath
2.0 timeframe, it may not be possible to define a DOM XPATH module
until the XPath 2.0 data model is reasonably stable. In any event,
the XPATH DOM must be defined in close coordination with the other
working groups addressing this issue.</li>
<li>The DOM XPATH interfaces SHOULD be based as much as possible on
the ideas and experiences of DOM implementers that have added XPath
extensions.</li>
<li>The DOM XPATH interfaces SHOULD NOT return a "live" object, but
should return a list or iterator that will either reflect a
snapshot of the DOM tree at the moment the XPath query was
evaluated or will become invalidated if changes to the DOM tree
could affect its contents.</li>
</ol>
</div>
<!-- div3 xpath-requirements -->
<div class='div3'><a name='dom-level-3-requirements-xpath-issues'
id="dom-level-3-requirements-xpath-issues"></a>
<h3 id='dom-level-3-requirements-xpath-issues-h3' class='div3'>
4.6.4 Known Questions</h3>
<ol>
<li>It is an open issue whether the DOM WG should wait for the
XPath 2.0 data model to emerge, or whether some interim solution
for the XPath 1.0 data model (mapped onto the DOM data model) is
preferable.</li>
<li>T he obvious place to put an XPath method is on the Node
interface, but we presumably do not want to make this required for
DOM compliance. (We suspect that the XPath module would be
implemented primarily by vendors already implementing XSLT, and
could be quite burdensome for other developers to support).</li>
<li>Do we want to put any requirements on the type of object
returned by an XPath locator? NodeLists are "live", which could
cause problems for implementers. NodeIterators are perhaps more
appropriate, but are not supported by existing XPath extensions to
the DOM.</li>
<li>What about other contextual factors besides namespaces? Do we
want to allow variables and non-standard functions to be defined to
the XPath engine?</li>
</ol>
</div>
<!-- div3 xpath-issues --></div>
<!-- div2 level3-xpath --></div>
<!-- div1 Level3 -->
</body>
</html>