You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1457 lines
64 KiB
1457 lines
64 KiB
<!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é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>
|
|
©2004 <a href='http://www.w3.org/'><abbr title=
|
|
'World Wide Web Consortium'>W3C</abbr></a><sup>®</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 <object>
|
|
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>
|