Re: Level 3 Core comments

> 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 DOMImplementationRegistry query the list of DOM
implementations. Given the query, it will be up to the
DOMImplementationSource to return a DOMImplementation or not. "XML 3.0
Events 3.0" may return a different implementation than "XML
3.0". Picking which implementation is the best given the query is up to
the source. The source may (and will) be provided be default inside the
DOM implementation package. For Java, the property will be given in the
jar file for example. Or I may decide to provide my own source based on
other criteria. It is correct that the list must be parsed by each
DOMImplementationSource but we don't expect the users to call this
method more than once in their DOM application, don't we?

>     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? 

A feature name must be valid XML, therefore it cannot start with a
number.

> 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.

agreed.

>     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?)?

We matched the replaceChild method in that case: the DOM implementation
may raise an error if it does not support the renaming of the document
element and the DocumentType node is not updated if it does.

>     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.

I renamed the name of the parameter to match
createElementNS/createAttributeNS. Once the parameter is renamed to
qualifiedName, the description of NAMESPACE_ERR makes more sense.

> 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?

have a look at:
http://lists.w3.org/Archives/Public/www-dom/2002OctDec/0117.html
 
> Typos:
> [...]

Fixed.
 
Philippe

Received on Wednesday, 6 November 2002 16:23:07 UTC