RE: Question about getNextSibling/getPre

Mike,

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

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

Regards,
Alfie.

 ----------
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   
lists;
another might use an array of arrays.  However one navigates the native
data structures, we want convenient, standardized DOM methods to work.   
 So
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   
help
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   
their
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   
on
one or the other.

Received on Tuesday, 10 March 1998 04:42:44 UTC