This document is also available in these non-normative formats: XML file plain text, PostScript file, PDF file, single HTML file, and ZIP file.
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This specification defines the Document Object Model Validation Level 3, a platform- and language-neutral interface. This module provides the guidance to programs and scripts to dynamically update the content and the structure of documents while ensuring that the document remains valid, or to ensure that the document becomes valid.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a Last Call Working Draft for review by W3C members and other interested parties. The Last Call review period ends on 27 November 2002. Please send reviews before the review period ends to the public mailing list www-dom@w3.org. An archive is available at http://lists.w3.org/Archives/Public/www-dom/.
Individuals or organizations are also invited to send a message to the public mailing list if they intend to produce an implementation of this module.
It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the DOM working group.
This document has been produced as part of the W3C DOM Activity. The authors of this document are the DOM WG members.
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
Copyright © 2002 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.
This document is published under the W3C Document Copyright Notice and License. The bindings within this document are published under the W3C Software Copyright Notice and License. The software license requires "Notice of any changes or modifications to the W3C files, including the date changes were made." Consequently, modified versions of the DOM bindings must document that they do not conform to the W3C standard; in the case of the IDL definitions, the pragma prefix can no longer be 'w3c.org'; in the case of the Java language binding, the package names can no longer be in the 'org.w3c' package.
Note: This section is a copy of the W3C Document Notice and License and could be found at http://www.w3.org/Consortium/Legal/copyright-documents-19990405.
Copyright © 1994-2002 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.
http://www.w3.org/Consortium/Legal/
Public documents on the W3C site are provided by the copyright holders under the following license. The software or Document Type Definitions (DTDs) associated with W3C specifications are governed by the Software Notice. By using and/or copying this document, or the W3C document from which this statement is linked, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and distribute the contents of this document, or the W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use:
When space permits, inclusion of the full text of this NOTICE should be provided. We request that authorship attribution be provided in any software, documents, or other items or products that you create pursuant to the implementation of the contents of this document, or any portion thereof.
No right to create modifications or derivatives of W3C documents is granted pursuant to this license. However, if additional requirements (documented in the Copyright FAQ) are satisfied, the right to create modifications or derivatives is sometimes granted by the W3C to individuals complying with those requirements.
THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.
Note: This section is a copy of the W3C Software Copyright Notice and License and could be found at http://www.w3.org/Consortium/Legal/copyright-software-19980720
Copyright © 1994-2002 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.
http://www.w3.org/Consortium/Legal/
This W3C work (including software, documents, or other related items) is being provided by the copyright holders under the following license. By obtaining, using and/or copying this work, you (the licensee) agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and modify this software and its documentation, with or without modification, for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the software and documentation or portions thereof, including modifications, that you make:
THIS SOFTWARE AND DOCUMENTATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE SOFTWARE OR DOCUMENTATION.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the software without specific, written prior permission. Title to copyright in this software and any associated documentation will at all times remain with copyright holders.
This chapter describes the optional DOM Level 3 Validation feature. This module provides APIs to query information about the XML document.
A DOM application can use the hasFeature
method of
the DOMImplementation
interface to determine whether a
given DOM supports these capabilities or not. This module defines 1
feature string: "VAL-DOC"
for document-editing
interfaces.
This chapter focuses on the editing aspects used in the XML document-editing world and usage of such information.
In the October 9, 1997 DOM requirements document, the following appeared: "There will be a way to determine the presence of a DTD. There will be a way to add, remove, and change declarations in the underlying DTD (if available). There will be a way to test conformance of all or part of the given document against a DTD (if available)." In later discussions, the following was added, "There will be a way to query element/attribute (and maybe other) declarations in the underlying DTD (if available)," supplementing the primitive support for these in Level 1.
That work was deferred past Level 2, in the hope that XML Schemas would be addressed as well. Work was deferred on lowest common denominator general grammar APIs due to heightened interest in XML Schema- specific APIs; however, work on querying information on the grammar was only done for DOM Level 3.
Here are the following use cases and requirements that prompted the functionality in this document:
Use Cases:
Requirements:
This section describes the "VAL-DOC" exceptions.
These operations may throw a ExceptionVAL
as
described in their descriptions.
exception ExceptionVAL { unsigned short code; }; // ExceptionVALCode const unsigned short NO_GRAMMAR_AVAILABLE = 71; const unsigned short VALIDATION_ERR = 72;
An integer indicating the type of error generated.
NO_GRAMMAR_AVAILABLE
DocumentEditVAL
related to the node does not have any grammar and
wfValidityCheckLevel
is set to PARTIAL
or
STRICT_VALIDITY_CHECK
.VALIDATION_ERR
This section contains "Document-editing" methods (includes
Node
, Element
, Text
and
Document
methods).
A DOM application may use the hasFeature(feature,
version)
method of the DOMImplementation
interface with parameter values "VAL-DOC" and "3.0" (respectively)
to determine whether or not the Document-Editing interfaces are
supported by the implementation.
This interface extends the NodeEditVAL
interface with additional methods for document editing.
interface DocumentEditVAL : NodeEditVAL { attribute boolean continuousValidityChecking; void validateDocument() raises(ExceptionVAL); };
continuousValidityChecking
of type boolean
true
will result in an exception being thrown, i.e.,
VALIDATION_ERR
,
for documents that are invalid at the time of the call. When set to
true, the implementation if free to raise the VALIDATION_ERR
exception on DOM operations that would make the document invalid
with respect to "partial validity." If the document is invalid,
then this attribute will remain false
. This attribute
is false
by default.validateDocument
NO_GRAMMAR_AVAILABLE: Raised if an error occurs when the grammar is not available for the document. |
This interface is similar to the [DOM Level 3 Core]
Node
interfaces, with methods for guided document
editing.
interface NodeEditVAL { // CheckTypeVAL const unsigned short WF_CHECK = 1; const unsigned short NS_WF_CHECK = 2; const unsigned short PARTIAL_VALIDITY_CHECK = 3; const unsigned short STRICT_VALIDITY_CHECK = 4; boolean canInsertBefore(in Node newChild, in Node refChild); boolean canRemoveChild(in Node oldChild); boolean canReplaceChild(in Node newChild, in Node oldChild); boolean canAppendChild(in Node newChild); boolean isNodeValid(in boolean deep, in unsigned short wFValidityCheckLevel) raises(ExceptionVAL); };
An integer indicating which type of validation this is.
NS_WF_CHECK
WF_CHECK
.PARTIAL_VALIDITY_CHECK
NS_WF_CHECK
.STRICT_VALIDITY_CHECK
NS_WF_CHECK
.WF_CHECK
canAppendChild
Node.appendChild
.
newChild
of type
Node
Node
to be appended.
|
|
canInsertBefore
Node.insertBefore
operation would make this document
not partially valid with respect to the currently active grammar.
newChild
of type
Node
Node
to be inserted.refChild
of type
Node
Node
.
|
|
canRemoveChild
Node.removeChild
.
oldChild
of type
Node
Node
to be removed.
|
|
canReplaceChild
Node.replaceChild
.
newChild
of type
Node
Node
.oldChild
of type
Node
Node
to be replaced.
|
|
isNodeValid
deep
of type
boolean
deep
flag on causes the
isNodeValid
method to check for the whole subtree of
the current node for validity. Setting it to false
only checks the current node and its immediate child nodes. The
validateDocument
method on the
DocumentVAL
interface, however, checks to determine
whether the entire document is valid.wFValidityCheckLevel
of
type unsigned short
|
|
NO_GRAMMAR_AVAILABLE: Exception is raised if the DocumentEditVAL
related to this node does not have any grammar associated with it
and |
This interface extends the Element
interface with
additional methods for guided document editing. An object
implementing this interface must also implement NodeEditVAL
interface.
interface ElementEditVAL : NodeEditVAL { readonly attribute NodeList definedElementTypes; unsigned short contentType(); boolean canSetAttribute(in DOMString attrname, in DOMString attrval); boolean canSetAttributeNode(in Attr attrNode); boolean canSetAttributeNS(in DOMString namespaceURI, in DOMString qualifiedName, in DOMString value); boolean canRemoveAttribute(in DOMString attrname); boolean canRemoveAttributeNS(in DOMString namespaceURI, in DOMString localName); boolean canRemoveAttributeNode(in Node attrNode); NodeList getChildElements(); NodeList getParentElements(); NodeList getAttributeList(); boolean isElementDefined(in DOMString name); boolean isElementDefinedNS(in DOMString name, in DOMString namespaceURI); };
definedElementTypes
of type NodeList
, readonlycanRemoveAttribute
attrname
of type
DOMString
|
|
canRemoveAttributeNS
namespaceURI
of type
DOMString
localName
of type
DOMString
|
|
canRemoveAttributeNode
attrNode
of type
Node
Attr
node to remove from the attribute
list.
|
|
canSetAttribute
attrname
of type
DOMString
attrval
of type
DOMString
|
|
canSetAttributeNS
setAttributeNS
.
namespaceURI
of type
DOMString
namespaceURI
of namespace.qualifiedName
of type
DOMString
value
of type
DOMString
|
|
canSetAttributeNode
attrNode
of type
Attr
Node
in which the attribute can possibly be
set.
|
|
contentType
|
Constant for one of |
getAttributeList
NodeList
containing all
the possible Attr
s that can appear with this type of
element. These are not nodes from the instance document, but rather
are new nodes that could be inserted in the document.
|
List of possible attributes of this element. |
getChildElements
NodeList
containing the
possible Element
nodes that can appear as children of
this type of element, with certain conditions as specified below.
These are not nodes from the instance document, but rather are new
nodes that could be inserted in the document.
|
List of possible children element types of this element. Note
that if no context of this element exists, then a |
getParentElements
NodeList
containing the
possible Element
nodes that can appear as a parent of
this type of element, with certain conditions as specified below.
These are not nodes from the instance document, but rather are new
nodes that could be inserted in the document.
|
List of possible parent element types of this element. Note that
if no context of this element exists, for example, the parent
element of this element, then a |
isElementDefined
name
is defined in
the currently active grammar.
name
of type
DOMString
|
A boolean that is |
isElementDefinedNS
name
in this
namespace is defined in the currently active grammar.
name
of type
DOMString
namespaceURI
of type
DOMString
namespaceURI
of namespace.
|
A boolean that is |
This interface extends the NodeEditVAL
interface with additional methods for document editing. An object
implementing this interface must also implement NodeEditVAL
interface.
interface CharacterDataEditVAL : NodeEditVAL { readonly attribute boolean isWhitespaceOnly; boolean canSetData(in unsigned long offset, in DOMString arg); boolean canAppendData(in DOMString arg); boolean canReplaceData(in unsigned long offset, in unsigned long count, in DOMString arg); boolean canInsertData(in unsigned long offset, in DOMString arg); boolean canDeleteData(in unsigned long offset, in unsigned long count); };
isWhitespaceOnly
of type boolean
, readonlytrue
if content only whitespace;
false
for non-whitespace.canAppendData
arg
of type
DOMString
|
|
canDeleteData
offset
of type
unsigned long
count
of type
unsigned long
|
|
canInsertData
offset
of type
unsigned long
arg
of type
DOMString
|
|
canReplaceData
offset
of type
unsigned long
count
of type
unsigned long
arg
of type
DOMString
|
|
canSetData
offset
of type
unsigned long
arg
of type
DOMString
|
|
Applications would like to be able to use functionality to guide construction and editing of documents, which falls into the document-editing world. Examples of this sort of guided editing already exist, and are becoming more common. The necessary queries can be phrased in several ways, the most useful of which may be a combination of "what does the DTD allow me to insert here" and "if I insert this here, will the document still be valid". The former is better suited to presentation to humans via a user interface, and when taken together with sub-tree validation may subsume the latter.
It has been proposed that in addition to asking questions about specific parts of the grammar, there should be a reasonable way to obtain a list of all the defined symbols of a given type (element, attribute, entity) independent of whether they're valid in a given location; that might be useful in building a list in a user-interface, which could then be updated to reflect which of these are relevant for the program's current state.
Remember that namespaces also weigh in on this issue, in the case of attributes, a "can-this-go-there" may prompt a namespace-well-formedness check and warn you if you're about to conflict with or overwrite another attribute with the same namespaceURI/localName but different prefix, or same nodeName but different namespaceURI.
We have to deal with the fact that "the shortest distance between two valid documents may be through an invalid one". Users may want to know several levels of detail (all the possible children, those which would be valid given what precedes this point, those which would be valid given both preceding and following siblings). Also, once XML Schemas introduce context sensitive validity, we may have to consider the effect of children as well as the individual node being inserted.
The most obvious use for a DTD or XML Schema or any grammar is to use it to validate a given XML document. This again falls into the document-editing world. The XML spec only discusses performing this test at the time the document is loaded into the "processor", which most of us have taken to mean that this check should be performed at parse time. But it is obviously desirable to be able to validate again a document -- or selected subtrees -- at other times. One such case would be validating an edited or newly constructed document before serializing it or otherwise passing it to other users. This issue also arises if the "internal subset" is altered -- or if the grammar changes.
In the past, the DOM has allowed users to create invalid
documents, and assumed the serializer would accept the task of
detecting problems and announcing/repairing them when the document
was written out in XML syntax... or that they would be checked for
validity when read back in. We considered adding validity checks to
the DOM's existing editing operations to prevent creation of
invalid documents, but are currently inclined against this for
several reasons. First, it would impose a significant amount of
computational overhead to the DOM, which might be unnecessary in
many situations, e.g., if the change is occurring in a context
where we know the result will be valid. Second, "the shortest
distance between two good documents may be through a bad document".
Preventing a document from becoming temporarily invalid may impose
a considerable amount of additional work on higher-level code and
users Hence our current plan is to continue to permit editing to
produce invalid DOMs, but provide operations which permit a user to
check the validity of a node on demand. If needed one can use
continuousValidityChecking
flag to ensure that the DOM
remains valid during the editing process.
Note that validation includes checking that ID attributes are unique, and that IDREFs point to IDs which actually exist.
XML defined the "well-formed" (WF) state for documents which are parsed without reference to their DTDs. Knowing that a document is well-formed may be useful by itself even when a DTD is available. For example, users may wish to deliberately save an invalid document, perhaps as a checkpoint before further editing. Hence, the "Validation" features will permit both full validity checking (see previous section) and "lightweight" WF checking, as requested by the caller, as well as processing entity declarations in the AS even if validation is not turned on.
While the DOM inherently enforces some of XML's well-formedness conditions (proper nesting of elements, constraints on which children may be placed within each node), there are some checks that are not yet performed. These include:
In addition, Namespaces introduce their own concepts of well-formedness. Specifically:
namespaceNormalize
operation, which would
create the implied declarations and reconcile conflicts in some
reasonably standardized manner. This may be a major undertaking,
since some DOMs may be using the namespace to direct subclassing of
the nodes or similar special treatment; as with the existing
normalize
method, you may be left with a
different-but-equivalent set of node objects.In the past, the DOM has allowed users to create documents which violate these rules, and assumed the serializer would accept the task of detecting problems and announcing/repairing them when the document was written out in XML syntax. We considered adding WF checks to the DOM's existing editing operations to prevent WF violations from arising, but are currently inclined against this for two reasons. First, it would impose a significant amount of computational overhead to the DOM, which might be unnecessary in many situations (for example, if the change is occurring in a context where we know the illegal characters have already been prevented from arising). Second, "the shortest distance between two good documents may be through a bad document" -- preventing a document from becoming temporarily ill-formed may impose a considerable amount of additional work on higher-level code and users. (Note possible issue for Serialization: In some applications, being able to save and reload marginally poorly-formed DOMs might be useful -- editor checkpoint files, for example.) Hence our current plan is to continue to permit editing to produce ill-formed DOMs, but provide operations which permit a user to check the well-formedness of a node on demand, and possibly provide some of the primitive (e.g., string-checking) functions directly.
This appendix contains the complete OMG IDL [OMG IDL] for the Level 3 Document Object Model Validation definitions.
The IDL files are also available as: http://www.w3.org/TR/2002/WD-DOM-Level-3-Val-20021008/idl.zip
// File: validation.idl #ifndef _VALIDATION_IDL_ #define _VALIDATION_IDL_ #include "dom.idl" #pragma prefix "dom.w3c.org" module validation { typedef dom::Node Node; typedef dom::NodeList NodeList; typedef dom::DOMString DOMString; typedef dom::Attr Attr; exception ExceptionVAL { unsigned short code; }; // ExceptionVALCode const unsigned short NO_GRAMMAR_AVAILABLE = 71; const unsigned short VALIDATION_ERR = 72; interface NodeEditVAL { // CheckTypeVAL const unsigned short WF_CHECK = 1; const unsigned short NS_WF_CHECK = 2; const unsigned short PARTIAL_VALIDITY_CHECK = 3; const unsigned short STRICT_VALIDITY_CHECK = 4; boolean canInsertBefore(in Node newChild, in Node refChild); boolean canRemoveChild(in Node oldChild); boolean canReplaceChild(in Node newChild, in Node oldChild); boolean canAppendChild(in Node newChild); boolean isNodeValid(in boolean deep, in unsigned short wFValidityCheckLevel) raises(ExceptionVAL); }; interface ElementEditVAL : NodeEditVAL { readonly attribute NodeList definedElementTypes; unsigned short contentType(); boolean canSetAttribute(in DOMString attrname, in DOMString attrval); boolean canSetAttributeNode(in Attr attrNode); boolean canSetAttributeNS(in DOMString namespaceURI, in DOMString qualifiedName, in DOMString value); boolean canRemoveAttribute(in DOMString attrname); boolean canRemoveAttributeNS(in DOMString namespaceURI, in DOMString localName); boolean canRemoveAttributeNode(in Node attrNode); NodeList getChildElements(); NodeList getParentElements(); NodeList getAttributeList(); boolean isElementDefined(in DOMString name); boolean isElementDefinedNS(in DOMString name, in DOMString namespaceURI); }; interface CharacterDataEditVAL : NodeEditVAL { readonly attribute boolean isWhitespaceOnly; boolean canSetData(in unsigned long offset, in DOMString arg); boolean canAppendData(in DOMString arg); boolean canReplaceData(in unsigned long offset, in unsigned long count, in DOMString arg); boolean canInsertData(in unsigned long offset, in DOMString arg); boolean canDeleteData(in unsigned long offset, in unsigned long count); }; interface DocumentEditVAL : NodeEditVAL { attribute boolean continuousValidityChecking; void validateDocument() raises(ExceptionVAL); }; }; #endif // _VALIDATION_IDL_
This appendix contains the complete Java [Java] bindings for the Level 3 Document Object Model Validation.
The Java files are also available as http://www.w3.org/TR/2002/WD-DOM-Level-3-Val-20021008/java-binding.zip
package org.w3c.dom.validation; public class ExceptionVAL extends RuntimeException { public ExceptionVAL(short code, String message) { super(message); this.code = code; } public short code; // ExceptionVALCode public static final short NO_GRAMMAR_AVAILABLE = 71; public static final short VALIDATION_ERR = 72; }
package org.w3c.dom.validation; public interface DocumentEditVAL extends NodeEditVAL { public boolean getContinuousValidityChecking(); public void setContinuousValidityChecking(boolean continuousValidityChecking); public void validateDocument() throws ExceptionVAL; }
package org.w3c.dom.validation; import org.w3c.dom.Node; public interface NodeEditVAL { // CheckTypeVAL public static final short WF_CHECK = 1; public static final short NS_WF_CHECK = 2; public static final short PARTIAL_VALIDITY_CHECK = 3; public static final short STRICT_VALIDITY_CHECK = 4; public boolean canInsertBefore(Node newChild, Node refChild); public boolean canRemoveChild(Node oldChild); public boolean canReplaceChild(Node newChild, Node oldChild); public boolean canAppendChild(Node newChild); public boolean isNodeValid(boolean deep, short wFValidityCheckLevel) throws ExceptionVAL; }
package org.w3c.dom.validation; import org.w3c.dom.Node; import org.w3c.dom.NodeList; import org.w3c.dom.Attr; public interface ElementEditVAL extends NodeEditVAL { public NodeList getDefinedElementTypes(); public short contentType(); public boolean canSetAttribute(String attrname, String attrval); public boolean canSetAttributeNode(Attr attrNode); public boolean canSetAttributeNS(String namespaceURI, String qualifiedName, String value); public boolean canRemoveAttribute(String attrname); public boolean canRemoveAttributeNS(String namespaceURI, String localName); public boolean canRemoveAttributeNode(Node attrNode); public NodeList getChildElements(); public NodeList getParentElements(); public NodeList getAttributeList(); public boolean isElementDefined(String name); public boolean isElementDefinedNS(String name, String namespaceURI); }
package org.w3c.dom.validation; public interface CharacterDataEditVAL extends NodeEditVAL { public boolean getIsWhitespaceOnly(); public boolean canSetData(int offset, String arg); public boolean canAppendData(String arg); public boolean canReplaceData(int offset, int count, String arg); public boolean canInsertData(int offset, String arg); public boolean canDeleteData(int offset, int count); }
This appendix contains the complete ECMAScript [ECMAScript] binding for the Level 3 Document Object Model Validation definitions.
Many people contributed to the DOM specifications (Level 1, 2 or 3), including members of the DOM Working Group and the DOM Interest Group. We especially thank the following:
Andrew Watson (Object Management Group), Andy Heninger (IBM), Angel Diaz (IBM), Arnaud Le Hors (W3C and IBM), Ashok Malhotra (IBM and Microsoft), Ben Chang (Oracle), Bill Smith (Sun), Bill Shea (Merrill Lynch), Bob Sutor (IBM), Chris Lovett (Microsoft), Chris Wilson (Microsoft), David Brownell (Sun), David Ezell (Hewlett Packard Company), David Singer (IBM), Dimitris Dimitriadis (Improve AB), Don Park (invited), Elena Litani (IBM), Eric Vasilik (Microsoft), Gavin Nicol (INSO), Ian Jacobs (W3C), James Clark (invited), James Davidson (Sun), Jared Sorensen (Novell), Jeroen van Rotterdam (X-Hive Corporation), Joe Kesselman (IBM), Joe Lapp (webMethods), Joe Marini (Macromedia), Johnny Stenback (Netscape/AOL), Jon Ferraiolo (Adobe), Jonathan Marsh (Microsoft), Jonathan Robie (Texcel Research and Software AG), Kim Adamson-Sharpe (SoftQuad Software Inc.), Lauren Wood (SoftQuad Software Inc., former Chair), Laurence Cable (Sun), Mark Davis (IBM), Mark Scardina (Oracle), Martin Dürst (W3C), Mary Brady (NIST), Mick Goulish (Software AG), Mike Champion (Arbortext and Software AG), Miles Sabin (Cromwell Media), Patti Lutsky (Arbortext), Paul Grosso (Arbortext), Peter Sharpe (SoftQuad Software Inc.), Phil Karlton (Netscape), Philippe Le Hégaret (W3C, W3C team contact and former Chair), Ramesh Lekshmynarayanan (Merrill Lynch), Ray Whitmer (iMall, Excite@Home, and Netscape/AOL, Chair), Rezaur Rahman (Intel), Rich Rollman (Microsoft), Rick Gessner (Netscape), Rick Jelliffe (invited), Rob Relyea (Microsoft), Scott Isaacs (Microsoft), Sharon Adler (INSO), Steve Byrne (JavaSoft), Tim Bray (invited), Tim Yu (Oracle), Tom Pixley (Netscape/AOL), Vidur Apparao (Netscape), Vinod Anupam (Lucent).
Thanks to all those who have helped to improve this specification by sending suggestions and corrections (Please, keep bugging us with your issues!).
This specification was written in XML. The HTML, OMG IDL, Java and ECMAScript bindings were all produced automatically.
Thanks to Joe English, author of cost, which was used as the basis for producing DOM Level 1. Thanks also to Gavin Nicol, who wrote the scripts which run on top of cost. Arnaud Le Hors and Philippe Le Hégaret maintained the scripts.
After DOM Level 1, we used Xerces as the basis DOM implementation and wish to thank the authors. Philippe Le Hégaret and Arnaud Le Hors wrote the Java programs which are the DOM application.
Thanks also to Jan Kärrman, author of html2ps, which we use in creating the PostScript version of the specification.
Several of the following term definitions have been borrowed or modified from similar definitions in other W3C or standards documents. See the links within the definitions for more information.
Document
.
This element node is a child of the Document
node. See
Well-Formed
XML Documents in XML [XML 1.0].For the latest version of any W3C specification please consult the list of W3C Technical Reports available at http://www.w3.org/TR.