W3C DOM Level 3 Issues List

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

This is the official issues list for the DOM Level 3 Core and Load/Save Proposed Recommendation period.

Status of this Document

This document contains a list of issues regarding the DOM Level 3 Core and DOM Level 3 Load and Save Proposed Recommendation period. All comments or issues regarding the specification or this document must be reported to www-dom@w3.org (public archives) before march 5, 2004. After this date, we don't guarantee to take your comments into account before moving to W3C Recommendation.

DOM Working Group members: see also the W3C Member-only bugzilla for non-official issues.

Issue summary (7 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: TitleStateTypeAck.
utf16 : writeToString, write and, UTF-16[BE|LE]agreedclarificationNo reply from reviewer
ls-stringData : stringData, and encoding declarationdeclinedclarificationNo reply from reviewer
xmlns-normalization : Namespace normalisation and Level 1 nodesdeclinedproposalNo reply from reviewer
character-normalization : 'check-character-normalization' underspecifiedagreedclarificationAgreement
entities : Stray mention of Entity in definitions of 'entities'agreededitorialAgreement
ls-parseURI : parseURI, parseFromURI, writeToURIdeclinederrorAgreement
contains_str : contains, and strdeclinederrorAgreement

State description

Decision cycle description

Issue details

utf16: writeToString, write and, UTF-16[BE|LE] [link to this issue]

The specification still needs to clarify the format of the DOMString if using LSSerializer.writeToString. it says that the declaration needs to be "UTF-16". But is it required to use a BOM?

Clarification concerning
LSSerializer.writeToString

Transition history

raised on 9 Feb 2004 by Kasimier Buchcik
agreed on 11 Feb 2004

No. a DOMString object never contains a BOM, since it is a character oriented output.

Acknowledgment cycle
announced by group on 19 Feb 2004

ls-stringData: stringData, and encoding declaration [link to this issue]

I learned that the LSSerializer should generate an encoding declaration of "UTF-16" if serializing a whole DOM document to a DOMString via LSSerializer.writeToString.

So just to have it black on white: does this imply the encoding declaration *has to* be existent and *has to* state "UTF-16", if parsing with LSParser.parse with an input.stringData holding a XML document - otherwise an error would be reported?

Transition history

raised on 25 Feb 2004 by Kasimier Buchcik
declined on 27 Feb 2004

It is not a requirement to have an XML declaration. If an XML declaration is present, the value of the encoding attribute will be ignored.

Acknowledgment cycle
announced by group on 27 Feb 2004

xmlns-normalization: Namespace normalisation and Level 1 nodes [link to this issue]

Reporting an error when the namespace algorithm encounters a DOM Level 1 node is undesirable. It would mean you'd be unable to serialise any document containing Level 1 Elements (or Attrs) without deliberately setting the DOMConfiguration parameter 'namespaces' to false. Raising a warning may be appropriate, but making it an error (so that by default processing stops altogether) seems excessively harsh and likely to bite application authors a lot.

Proposal concerning
Document.renameNode

Transition history

raised on 19 Feb 2004 by Andrew Clover
declined on 25 Feb 2004

This is correct. DOM Level 1 applications need to be careful about this before invoking a load, parse, or normalizeDocument methods. We still believe that it is dangerous to mix non-namespaces and namespaces aware nodes in the same tree. This reflects a design problem in the DOM application. The default processing may not cause the processing to stop if the error can be recovered. Continuing the processing if the mistake cannot be recovered would be harmful if the document is being serialized for example. If the processor believes that the error can be recovered, it is free to continue the processing.

Acknowledgment cycle
announced by group on 26 Feb 2004

character-normalization: 'check-character-normalization' underspecified [link to this issue]

What actions should be expected if a character in the document is not fully normalized? I'd assume that an error should be dispatched, but the spec doesn't say.

What should be the behavior if both check-character-normalization and normalize-characters are specified as true? Are there any interaction between the parameters? It might make sense that setting one unsets the other.

Discussion history
24 Feb 2004, 25 Feb 2004

Transition history

raised on 24 Feb 2004 by Curt Arnold
agreed on 27 Feb 2004

added 'check-character-normalization-failure', as an error, on check-character-normalization.

Acknowledgment cycle
announced by group on 27 Feb 2004
agreement by reviewer on 27 Feb 2004

entities: Stray mention of Entity in definitions of 'entities' [link to this issue]

"Only EntityReference nodes to non-defined entities are kept in the document, with their associated Entity nodes if any."

The phrase "with their associated Entity nodes if any" is a hold-over from the previous definition of "entities" and should be eliminated.

Transition history

raised on 24 Feb 2004 by Curt Arnold
agreed on 27 Feb 2004

+1

Acknowledgment cycle
announced by group on 27 Feb 2004
agreement by reviewer on 27 Feb 2004

ls-parseURI: parseURI, parseFromURI, writeToURI [link to this issue]

"LSSerializer.parseURI" should be renamed to "LSSerializer.parseFromURI" - analogous to "LSParser.writeToURI"

Error concerning
LSParser.parseURI

Transition history

raised on 19 Feb 2004 by Kasimier Buchcik
declined on 23 Feb 2004

The current implementers of DOM Level 3 Core that are participating in the Working Group were against changing the method name at this stage of the W3C Recommendation track. So there is no plan to change the method name.

Acknowledgment cycle
announced by group on 27 Feb 2004
agreement by reviewer on 27 Feb 2004

contains_str: contains, and str [link to this issue]

NameList.contains takes a "str", although NameList.contains takes a "name". Maby NameList.contains(in DOMString name) would be more adequate here.

Error concerning
NameList.contains

Transition history

raised on 23 Feb 2004 by Kasimier Buchcik
declined on 23 Feb 2004

The parameter was renamed to match DOMStringList.contains(str), following an issue brought by the DOM TS effort.

Acknowledgment cycle
announced by group on 23 Feb 2004
agreement by reviewer on 23 Feb 2004

Maintained by DOM Working Group.

Last update: $Date: 2004/02/27 23:10:01 $


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