W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1998

RE: Question about getNextSibling/getPre

From: Alfie Kirkpatrick <akirkpatrick@ims-global.com>
Date: Tue, 10 Mar 1998 9:35:14 +0000
Message-Id: <TFSHRNHX@ims-global.com>>
To: www-dom@w3.org, mcc@arbortext.com

Thanks a lot for the reply. My point is really that DOM nodes
may contain nodes from different implementors, correct? So,
I might take an existing DOM structure and insert my special
MyGraphicNode in there, which is an object which supports
the Node interface but possibly in a very different way. Also,
if an implementation supports previous/next pointers or an
"index in parent" value, how can the insert method on Node
actually do this, without knowing the precise implementation
of the Node being inserted and the nodes it already contains?

In my implementation, I don't assume anything other than
the basic Node interface when working with the nodes (only
the DOMFactory has that kind of access), so providing an
implementation specific method isn't an option.

Perhaps there should be a statement in the DOM spec about
whether or not nodes from different implementations can be

This brings up a related point. In COM, interfaces are identified
by GUIDs. Are there plans to release a Microsoft COM IDL file
which people can use for implementations? Otherwise, it will
be much harder for C++ applications to work with nodes from
different implementations. I'd be willing to help with this effort
since I have a fairly complete IDL file already.

I totally agree with your point on interoperability being the primary
aim. I've been working on creating DOM objects from XML (using
James' XMLPARSE source) and from SGML (using SP). Although
the interfaces are very different, the resulting tree is the same!
It's also amazing how much you can do with the document with
a simple VBScript program in a web page. I've been formatting
King Lear into frames/links/etc...


From:  mcc@arbortext.com
Sent:  09 March 1998 18:09
To:  www-dom@w3.org
Subject:  Re: Question about getNextSibling/getPreviou

For example, one implementation might use a tree of multiply-linked   
another might use an array of arrays.  However one navigates the native
data structures, we want convenient, standardized DOM methods to work.   
one implementation of getNextSibling might navigate via a Next pointer,
another might increment an array index; either would be efficient in that
implementation, but specifying too much implementation detail does not   
achieve the goals of the DOM.

Is that clearer?

One more point (that may or may not be a digression):  The DOM's primary
goal is to promote INTEROPERABILITY, not efficiency.  Assuming, for
example, that both Microsoft and Netscape support the DOM someday in   
browsers, the idea is that one can write a script, JavaBean, etc. that
works with both.  It may be that some approach is far more efficient in
implementation one than another, and the vendor is free to steer the DOM
programmer toward the more efficient approach on their particular
implementation (and of course the other vendor could steer the DOM
programmer toward a different approach).  Yet we'll consider the DOM a
success if the script/Bean/control WORKS on both even if it works BETTER   
one or the other.
Received on Tuesday, 10 March 1998 04:42:44 UTC

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