W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2003

DOM Level 3 Core 20030609 comments

From: Andrew Clover <and-w3@doxdesk.com>
Date: Wed, 11 Jun 2003 22:55:53 +0000
To: www-dom@w3.org
Message-ID: <20030611225553.GA10108@doxdesk.com>

Ray Whitmer <raydwhitmer@aol.com> wrote:

> The DOM WG asks for review of the following document:

> Document Object Model (DOM) Level 3 Core Specification

Looks reasonable from what I've read so far. Issues noticed:

1.2.3 (DOMUserData): the repeated wording "an application data" is rather
odd; 'data' is of course plural.

1.3.6 (features): the new method of prepending a '+' to the feature name
seems rather clumsy. If a Level 2 feature is updated to a Level 3 feature
which can be non-castable, an application that wants the Level 2 feature
and doesn't care about casting would have to call hasFeature twice to find
out whether the feature can be supplied, once with "+"..."3.0" and once with

Document.renameNode: it seems to be impossible to rename a node and end up
with a non-namespace (Level 1) node. For orthogonality, shouldn't there be
renameNode and renameNodeNS?

Text.wholeText: by my reading of the definition of "logically adjacent text
nodes", fooNode's wholeText should also give "barfoo". Is this a mistake?
If not, why is fooNode adjacent to barNode but not vice versa? If wholeText
is only supposed to look forwards, the spec should say so.

DOMError: still seems a bit vague. How exactly does a fatal error differ
from an error? Can an error handler be called for arbitrary DOM exceptions,
or just the few circumstances defined here? Are parse errors in Load/Save
going to cause DOMErrors? What should DOMErrorHandlers do with unrecognised
errors? Are the "wf-..." errors warnings?

(And given the allusions to changes in LS, can we expect a new Draft of this

DOMConfiguration parameter whitespace-in-element-content: "Discard all Text
nodes that contain whitespaces in element content" implies that Text nodes
in element content with *any* whitespace characters in their data should be
removed, rather than Text nodes composed *only* of whitespace. I'm pretty
sure this is not what was meant.

Interface CDATASection: "The DOMString attribute of the Text node..." -
surely "The data attribute...".

> The DOM WG is looking for implementations of the draft.

I've recently written a standalone Python 1.5-and-later module implementing
this Draft (above issues notwithstanding) and the February Draft of Load/Save.
(Beta testers welcomed.)

Andrew Clover
Received on Wednesday, 11 June 2003 19:05:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:11 UTC