This is the official issues list for the DOM Level 3 Core and Load/Save Proposed Recommendation period.
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.
Color key: error warning note
| Id:Title | State | Type | Ack. |
|---|---|---|---|
| utf16 : writeToString, write and, UTF-16[BE|LE] | agreed | clarification | No reply from reviewer |
| xmlns-normalization : Namespace normalisation and Level 1 nodes | declined | proposal | No reply from reviewer |
| ls-parseURI : parseURI, parseFromURI, writeToURI | declined | error | Agreement |
| contains_str : contains, and str | declined | error | Agreement |
| ls-stringData : stringData, and encoding declaration | declined | clarification | No reply from reviewer |
| character-normalization : 'check-character-normalization' underspecified | agreed | clarification | Agreement |
| entities : Stray mention of Entity in definitions of 'entities' | agreed | editorial | Agreement |
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?
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.
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.
"LSSerializer.parseURI" should be renamed to "LSSerializer.parseFromURI" - analogous to "LSParser.writeToURI"
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.
NameList.contains takes a "str", although NameList.contains takes a "name". Maby NameList.contains(in DOMString name) would be more adequate here.
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?
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.
"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.
Last update: $Date: 2004/02/27 23:10:01 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.