- From: Fred L. Drake, Jr. <fdrake@acm.org>
- Date: Thu, 1 Aug 2002 13:10:10 -0400
- To: www-dom@w3.org
I've started looking at the DOM Level 3 drafts again, and have come
across the following issues as I've started a preliminary
implementation for Python. (If anyone's interested, it's part of the
"minidom" implementation in PyXML: http://pyxml.sf.net/.)
These comments pertain to the "Core" specification. I've been
referring to the 9 April 2002 drafts, and have not as yet attempted to
implement all of this specification. (In particular, I have not
addressed the normalization features.)
1. DOMImplementationSource interface.
The big question is "Why?" The bootstrapping problem doesn't seem
to go away; the description refers to a "binding-specific list of
available sources". Why not just have a binding-specific list of
implementation objects? These could then be queried just as
effectively as a list of sources, and probably more efficiently as
well; the API presented for this interface requires that the list
of feature specifications be parsed by each implementation source,
rather than once.
The format of the string passed to the getDOMImplementation()
method also begs another question: How does an implementor tell
the difference between a version number and a feature name? It
*looks* obvious when read casually, but there needs to be some
guarantee that version numbers can be distinguished from feature
names. Stating that version numbers begin with a decimal digit
and feature names do not, and that neither can contain spaces,
would be sufficient.
2. Document.renameNode().
a. Is the NODE_RENAMED "event" fired on the UserDataHandler
object if the same node object is used for the renamed node?
Whether this is needed is entirely application specific, so it
makes sense to fire this event regardless and allow the
application to check for src == dst in their handle() method
if the distinction is relevant.
b. What special consideration needs to be made for the document
element? Does the "name" attribute of an associated
DOCUMENT_TYPE_NODE get updated if the document element is
renamed? Or is an exception thrown (and which one?)?
c. In the description of when NAMESPACE_ERR can be raised by this
method, reference is made to "qualifiedName", but there is no
such parameter. I'm sure this is just an editorial detail and
can be fixed easily; I'd suggest removing all but the last
sentence of that paragraph, and change "Also raised," to
"Raised" in the last sentence.
3. UserDataHandler.NODE_DELETED
It is not at all clear what it means for a node to be deleted.
Does it mean that the object is being finallized, or that the node
is has been removed from the document tree (possibly temporarily)?
How would it interact with persistent nodes, which move in and out
of memory?
Typos:
Document.strictErrorChecking description:
1st sentence: "errors checking" should be "error checking"
last sentence: "defaults" should be "default"
Document.renameNode() description:
2nd para, last sentence: "attach" should be "attached"
Text.replaceWholeText() description:
1st sentence: "the a specified" should be "the specified"
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
Received on Thursday, 1 August 2002 13:10:45 UTC