- 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