The document references appendix E of XML 1.1 when it meant to reference appendix B.

The description of DOMImplementationRegistry in the DOM Level 3 Core Java binding, does not mention that a service provider will be used if the system property is not set.

It would have been nice if it mentioned something similar to the description for the newInstance() method ... The DOMImplementationRegistry is initialized by the application or the implementation, depending on the context, by first checking the value of the Java system property org.w3c.dom.DOMImplementationSourceList and then the service provider whose contents are at META_INF/services/org.w3c.dom.DOMImplementationSourceList. The value of this property is a white-space separated list of names of available classes implementing the DOMImplementationSource interface.

The "well-formed" parameter in DOM Level 3 Load and Save references the "well-formed" parameter in Core. This means that when a not well-formed error of type "wf-invalid-character-in-node-name" and "wf-invalid-character" occurs while loading or saving a document, the value of DOMError.severity should be SEVERITY_ERROR since Core specifies this. Should the description of the "well-formed" parameter in the LS specification be modified to report an error of severity SEVERITY_FATAL_ERROR instead?

It might be worth mentioning in the spec the potential well-formedness errors that may arise during serialization when "namespace-declarations" is set to false, "namespaces" to true and "well-formed" to true.

Though the specification does not mention it, when a node is adopted, the UserData associated is carried over, right? A minor editorial point, noticed that the description for DOMUserDataHandler - handle(...) [1] mentions "This method is called whenever the node for which this handler is registered is imported or cloned". Is there any need to mention other operations namely adopted, deleted and renamed for which the method is invoked.

The parseURI method from the DOM Level 3 LS states: If the LSParser is a synchronous LSParser, the newly created and populated Document is returned, or null if an error occurred. Seems a bit odd, should null be returned when validation errors occur? The L3 Candidate Recommendation did not contain the condition "or null if an error occurred." What was the rationale behind this change to the PR?

According to the DOM Level 3 Core Recommendation for Document.adoptNode, Return Value: The adopted node, or null if this operation fails, such as when the source node comes from a different implementation. and Exceptions: NO_MODIFICATION_ALLOWED_ERR: Raised when the source node is read-only. So should an attempt to adopt a read-only node across DOM implementations return null or throw a DOMException or is this implementation dependant?

As part of the DHTML accessibility Roadmap effort we determined that one of the most critical issues with JavaScript is that user agents do not allow the author to give focus change to any element within the DOM. JavaScript authors treat all elements as active and will quite often place onclick and onmouseover event handlers on virtually any element, including DIVS and SPANS. Assistive technologies are designed to follow the users focus. It is the responsibility of the author to ensure that focus is given to an element so that the user and assistive technology can follow focus. In US Public law 508 this is provided indirectly by requiring that keyboard equivalents for all mouse actions.

DOM level 2 HTML indicates that the focus method is only provided for on anchors and form elements. In discussing the issue with Raman this document only reflects common practice on the web rather than what actually may be done. I feel this is the source of confusion. DOM level 2 for any element to be active within the DOM. If this is true then all elements should have the ability to receive focus.

Please clarify if the current implementation by user agents is incorrect? May all document elements receive focus?

If the response by the group is that the current interpretation is incorrect and that all elements may receive focus then the Mozilla team has agreed to correct this problem by adding the focus() method to all elements. If the response is that the interpretation is correct then we need to have reform.

User agents should also allow the author to dispatch DOMFocusIn, DOMFocusOut, and DOMActivate events to any element within the DOM. Currently Mozilla does not allow this. While it claims to support DOM2, DOMFocusIn, DOMFocusOut, and DOMActivate are not generated from the browser in response to an onclick or a mouse click. This make the script authoring more complex. In order to provide equal access to the keyboard, the author must map a handler for the keyboard click and mouseclick rather than simply responding to a DOMActivate.

Should the user agent:

There exists a possibility of a memory leak that can originate from DOMImplementationRegistry.java. If an IOException is thrown when the getServiceValue() method from DOMImplementationRegistry.java attempts to read a service provider to retrieve the resource META_INF/services/org.w3c.dom.DOMImplementationSourceList, the underlying InputStream is never closed and this may result in a memory leak. The method getServiceValue should read:

is the DOMException NO_DATA_ALLOWED_ERR referenced anywhere in the specs?

compareDocumentPosition does not say that its returned value is defined by the DocumentPosition constants.