W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Who manages this list?

From: Tom <Tom@HighPlaces.com>
Date: Fri, 1 May 1998 09:37:16 -0700
Message-ID: <002401bd751f$6ba19730$0e83b3cc@pc-obscura>
To: <www-dom@w3.org>

I am getting postings to this list apparently due to
some domain naming error, or bad entry on the
listserver, and I can't find any reference to the list manager.

Could someone email me as to who manages this list?



-----Original Message-----
From: Peter Sharpe <peter@sqwest.bc.ca>
To: www-dom@w3.org <www-dom@w3.org>
Date: Friday, May 01, 1998 9:36 AM
Subject: RE: Alternative to the Live NodeIterator

At 01:15 AM 5/1/98 , Andrew n marshall wrote:
>> -----Original Message-----
>> From: Mike Champion [mailto:mcc@arbortext.com]
>> Subject: Re: Alternative to the Live NodeIterator
> . . .
>>>  It seems to require that a globale list of all NodeIterators be
>>> somewhere, each with a abstract description of the search criteria.
>>> time a node is added (or worse, an entire tree), it has to compared
>>> search criteria and additional processing may be require to determine
>>> ordering.
>> I certainly hope not!  It has always been my assumption that each
>> NodeIterator knows where it points to in the tree (e.g., "after the Node
>> address 0xbeef0666"), and when a call comes to re-position the iterator
>> return its next or previous node, it would use the tree itself to
>> re-position it properly.
>The reference cannot be directly to the node; what if the referenced node
>So the reference must begin from some parent.  Then I have to ask how does
>this work if the reference node is deleted?  What if several nodes are
>deleted, destroying both indexes and identity references?
>I think either a backend event interface or a marker node within the tree
>required.  Both concepts require references to the node iterators.
I am going to answer these questions using fuzzy references to a possible
implementation. Don't take that to imply that I am recommending any
implementation, but it should give you some ideas about how I think
can be efficiently implemented. Your mail makes it clear that you have
thought about at least some of the things I'm going to say.

Any object which contains a reference to one or more nodes in the tree will
to be "maintained" during editing operations. There are many ways to
this, obviously, but one way, conceptually at least, is to have methods like
beforeDelete(Node nodeBeingDeleted), afterInsert(Node nodeBeingInserted),
If you implement your iterators as a linked list then on a Node delete
you can call
  myIteratorClass::beforeDelete(Node nodeBeingDeleted) {
    if nodeBeingDeleted is something I reference then
       fix up my reference by finding an appropriate node that will still
       be around after nodeBeingDeleted is gone.
It is easy and cheap to implement the iterators as a linked list, array, or
similar and the fixups that they have to do on a delete is very simple. I
don't see why you need to instead keep a reference to some parent.

In fact, I don't see how it would help you to have a reference to a parent
since you will want your iterators to work with Ranges as well and Ranges
remove large portions of the tree including all parents except the top-level
document node. (Note that to support Range editing operations beforeDelete()
should be overloaded to take a Range rather than a Node. The fixups won't
be much

I don't understand your comment about updating based on search criteria. As
as you fix up the reference in the iterator you can apply the search
the next time the iterator is moved. Unless maybe you are imagining creating
list of all hits and storing that. I would not recommend doing that as it
restrict the usefulness of your application to small documents that need to
completely parsed and, probably, in memory.

Peter Sharpe, Chief Scientist, SoftQuad Inc. Tel: +1 604 585 8394 ext. 312
#108-10070 King George Highway, Surrey, B.C., CANADA V3T 2W4 Fax: 585 1926
Internet: peter@sq.com or peter@sqwest.bc.ca World Wide Web:
Received on Friday, 1 May 1998 12:36:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:26 UTC