W3C DOM Level 3 Core Issues List

Inside: Issue summary | State description | Decision cycle description | Issue details (Validate data)

This is the official issues list for the DOM specifications.

Status of this Document

This document contains a list of issues regarding the DOM specifications. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives).

An XML version of this issues' list is also available.

Issue summary (12 issues)

Reformat summary with options:
Expert mode options
Hide columns:
Hide issues by type:
Hide issues by state:
Hide issues by acknowledgment:

Other views: types | states | concerning | reviewers | open actions

Changes between dates (YYYY-MM-DD) and [Optional]

For maintainers: new issue data | new issues list data

Color key: error warning note

Id:Title StateType
ls-1 : appendix E or B?no decision
(raised)
editorial
core-1 : DOMImplementationRegistry descriptionno decision
(raised)
proposal
ls-2 : well-formed parameter and errorsno decision
(raised)
error
ls-3 : well-formed, and namespaces parametersno decision
(raised)
clarification
core-2 : User data handling for adoption, deletion and renaming?no decision
(raised)
proposal
ls-4 : parseURI and null return valueno decision
(raised)
clarification
core-3 : adoptNode and failureno decision
(raised)
clarification
html-1 : focus and DOM Level 2 HTMLno decision
(raised)
clarification
events-1 : DOMFocusIn|Out, DOMActivateno decision
(raised)
clarification
core-4 : Memory leak in DOMImplementationRegistryno decision
(raised)
error
core-5 : NO_DATA_ALLOWED_ERR is not used?!?no decision
(raised)
error
core-6 : compareDocumentPosition and DocumentPositionno decision
(raised)
clarification

State description

Issue details

ls-1: appendix E or B? [link to this issue]

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

Editorial concerning
LSSerializer

Transition history

raised on 14 Apr 2004 by Venu

core-1: DOMImplementationRegistry description [link to this issue]

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."

Proposal concerning
Java Binding Extension

Transition history

raised on 14 Apr 2004 by Neil Delima

ls-2: well-formed parameter and errors [link to this issue]

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?

Error concerning

Transition history

raised on 30 Apr 2004 by Neil Delima

ls-3: well-formed, and namespaces parameters [link to this issue]

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.

Clarification concerning

Transition history

raised on 30 Apr 2004 by Neil Delima

core-2: User data handling for adoption, deletion and renaming? [link to this issue]

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.

Proposal concerning
UserDataEvent.handle

Transition history

raised on 30 Apr 2004 by Neil Delima

ls-4: parseURI and null return value [link to this issue]

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?

Clarification concerning
LSParser.parseURI
Discussion history
27 May 2004

Transition history

raised on 20 May 2004 by Neil Delima

core-3: adoptNode and failure [link to this issue]

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?

Clarification concerning
Document.adoptNode
Discussion history
27 May 2004

Transition history

raised on 20 May 2004 by Neil Delima

html-1: focus and DOM Level 2 HTML [link to this issue]

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.

Clarification concerning
DOM Level 2 HTML

Transition history

raised on 9 Jun 2004 by Richard Schwerdtfeger

events-1: DOMFocusIn|Out, DOMActivate [link to this issue]

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:

Clarification concerning
UIEvent

Transition history

raised on 9 Jun 2004 by Richard Schwerdtfeger

core-4: Memory leak in DOMImplementationRegistry [link to this issue]

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:

    private static String getServiceValue(final ClassLoader classLoader) {
	String serviceId = "META-INF/services/" + PROPERTY;
	InputStream is = null;
	BufferedReader rd = null;    
	String serviceValue = null;
	
	// try to find services in CLASSPATH
	try {
	    is = getResourceAsStream(classLoader, serviceId);
	    
	    if (is != null) {
		try {
		    rd =
			new BufferedReader(new InputStreamReader(is, "UTF-8"),
					   DEFAULT_LINE_LENGTH);
		} catch (java.io.UnsupportedEncodingException e) {
		    rd =
			new BufferedReader(new InputStreamReader(is),
					   DEFAULT_LINE_LENGTH);
		}		
		serviceValue = rd.readLine();
	    }
	} catch (Exception ex) {
	    return null;
	}
	finally {
	    if (rd != null) {
		try {
		    // try to close the reader.
		    rd.close();
		}
		// Ignore the exception.
		catch (Exception ex) {}
	    }    
	}
	
	if (serviceValue != null && serviceValue.length() > 0) {
	    return serviceValue;
	} else { 
	    return null;
	}    
    }
Error concerning
Java Binding Extension

Transition history

raised on 11 Jun 2004 by Neil Delima

core-5: NO_DATA_ALLOWED_ERR is not used?!? [link to this issue]

is the DOMExceptionNO_DATA_ALLOWED_ERR referenced anywhere in the specs?

Error concerning
NO_DATA_ALLOWED_ERR

Transition history

raised on 11 Jun 2004 by Neil Delima

core-6: compareDocumentPosition and DocumentPosition [link to this issue]

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

Clarification concerning

Transition history

raised on 28 Apr 2005 by Joe Kesselman

Maintained by DOM Interest Group.

Last update: $Date: 2005/05/10 14:07:40 $


This page was generated as part of the Extensible Issue Tracking System (ExIT)