W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Walking the DOM (was: XML APIs)

From: Stephen R. Savitzky <steve@rsv.ricoh.com>
Date: 03 Nov 1998 18:59:21 -0800
To: www-dom@w3.org
Message-ID: <qc90hsqi2e.fsf@gelion.crc.ricoh.com>
Claude Zervas <claude@utlco.com> writes:

> Again, I think that in light of all the severe disagreements about
> NodeList 'liveness' and iterator behaviour there should be a branching of
> the spec for applications that are not designed for naive script writers
> and where performance is of foremost importance.

I was beginning to think I was the only one with this opinion.

> This 'server-or-whatever' DOM would have at least the following
> characteristics:

Call 'em "features", and make their presence or absence detectable using
DOMImplementation's hasFeature method.

> 1. NodeLists do not need to be 'live'
> 2. Node.Next/PreviousSibling attributes are deprecated or are simply
> convenience methods that may (or may not) be horribly slow.

firstChild and parentNode, too.  

> 3. Iterators are introduced and provide behaviour that may
> be undefined if the tree is modified underneath them.
> I would also be ok with the idea that the iterators simply
> throw an exception if the tree is mutated.

Throwing an exception requires an O(log N) test somewhere.  

I would like to see iterators with something like the following interface:

   interface Iterator {
          readonly attribute  DOMString            nodeName;
                   attribute  DOMString            nodeValue;
          readonly attribute  unsigned short       nodeType;
          readonly attribute  Document             ownerDocument;

          boolean	toParentNode();
          boolean	toFirstChild();
	  boolean	toPreviousSibling();
          boolean	toNextSibling();
	  void		insertBefore(in Iterator newSibling)
	  void		insertAfter(in Iterator newSibling)
	  void		replace(in Iterator replacement)
          void		remove() 
          void		appendChild(in Iterator newChild)
          void		prependChild(in Iterator newChild)
          boolean	hasChildNodes();
	  boolean	isReadOnly();
          Node		cloneNode(in boolean deep);
	  Iterator	cloneIterator();
	  void		close();

	  boolean	toNamedChild(DOMString name);
	  Iterator	iterateAttributes();

Note that this has essentially all the characteristics of Node except that
you can never get at the node itself (though you _can_ get at a _clone_ of
it) or its children.  Such an iterator can be used, for example, to traverse
documents that are never entirely present in memory, or exist on a remote

Note also that all the structure-modification interfaces also take
Iterator instead of Node.  This lets you manipulate a document without
ever constructing a single Node -- you could make your parser be an
implementation of Iterator.

A practical DOM would, of course, have both Iterator and a NodeIterator or
TreeIterator that operates in the ``classical'' manner, with an accessible
current Node and taking Node operands for the editing operations.  Probably
a variety of others (e.g. ReadOnlyIterator) as well.

> 4. EntityReferences are really references and no copying is done.

With a method, getReferencedEntity(), to do the obvious.

> It would also be nice to have a standard DOM factory for creating objects
> outside of the context of a document. This is very useful for creating
> partial documents that can be used in templates, etc. (I'm thinking HTML
> DOM here).

I agree. 

 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/
Received on Tuesday, 3 November 1998 21:54:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC