Re: Nodes as NodeLists?

>At 08:29 PM 4/28/98 -0400, Jeff wrote:
>>>A node can have children, so the "collections" such as the external and
>>>internal subsets are stored as the set of children of the Node off of
>>>DocumentType.
>>
>>But in reality, the "container" nodes aren't really nodes.  Which means
that
>>a node in the DOM doesn't always translate into a "node" in the document.

This would also apply to attribute values in the Core specification. It
appears that
all occurrences of NodeList in previous versions of the spec were replaced
with Node. But that is not the case with the HTML interfaces (which still
uses NamedNodeList and possibly NodeList). Does the WG plan to align the XML
and HTML interfaces (at least in terms of the NodeIterator interface)?

>A NodeIterator would make sense here ... I'll bring this up in the WG.

Actually, a NodeIterator is not sufficient.  I understand the rationale
behind the NodeIterator. And I believe it is good for applications needing
"read" access to the DOM. However, I believe that the NodeIterator should
have replaced the NodeEnumerator--not NodeList and NamedNodeList. Both are
still necessary, for DOM implementations, for parsers, and for applications
needing "write" access to a model.

On a related note--there should never be any read-only attributes on any of
the DOM interfaces. If the goal of the DOM is interoperability, then the
specification MUST be complete enough so that implementations NEVER need to
rely on implementation-specific methods when creating an object model from a
document fragment.  If the goal is to eliminate implementation dependencies
from clients, then the interfaces don't need to be as complete.  The best
example of this problem is that there is no Node.setParentNode method--with
no setParentNode method, I can't take a node parsed by implementation a and
move it to a document parsed by implementation b  There may be other areas
that need the same modification.  If this isn't the intent, then it isn't a
problem. But it sure does litter implementations and parsers with
unnecessary casts.

Some other comments:

For anything "keyed" by name: attributes, attribute definitions, element
declarations, notation declarations, entity declarations, a NamedNodeList is
necessary.

It may be helpful, at least for XML documents, to be able to look up the
definition/declaration for an element, entity, notation, etc.  For example,
Element (or an XMLElement interface) could have a getElementDefinition
method, Attribute (or an XMLAttribute interface) could have a
getAttributeDefinition method, EntityReference could have a
getEntityDeclaration method. This would simplify some pretty common tasks.

The Node interface should have an append(Node child) method.
insertBefore(child, null) is not intuitive.  Also, the append method
wouldn't need to throw an exception--which makes creation of a document from
scratch much easier (don't need to catch all those pesky
NotMyChildExceptions that will never be thrown anyway).

Ok, that's enough for now...

Jeff Mackay
Vtopia, Inc.
url: http://www.vtopia.com/
e-mail: jmackay@vtopia.com

Received on Wednesday, 29 April 1998 01:40:27 UTC