W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2002

Level 3 Core comments

From: Fred L. Drake, Jr. <fdrake@acm.org>
Date: Thu, 1 Aug 2002 13:10:10 -0400
Message-ID: <15689.27506.633802.639940@grendel.zope.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT