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

RE: Question about getNextSibling/getPre

From: Mike Champion <mcc@arbortext.com>
Date: Tue, 10 Mar 1998 13:20:56 -0500
Message-Id: <98Mar10.132113est.18824@thicket.arbortext.com>
To: www-dom@w3.org

OK, I think I understand the scenarios now: A DOM client application ---
via COM, CORBA, direct calls into different DLLs, or via some other RPC
mechanism -- manipulates documents defined by different implementations of
the DOM API.  

One issue is "What should the DOM spec say about the limitations here?".
I'd be inclined to say something to the effect that the programmer should
remember that the various objects are just chararacterized by a common
INTERFACE, not a common STRUCTURE, so there is no reason to believe that
they can be intermingled in a single document.  Actually, in Provo we
agreed -- after about 4 hours of discussion -- that the elements of
multiple documents can't be intermingled EVEN WITHIN A SINGLE
IMPLEMENTATION. Thus, to copy a subtree from one document to another, it
will have to be cloned, Node by Node, copying values from the source to the
target objects.

Another issue would be "What should the DOM WG do to make this easier?" I'm
at a bit of a loss to suggest much that could go into Level 1.  Maybe CORBA
or COM would help the cause here, but this would be outside the scope of
the DOM.  Also, maybe a DOM-friendly "repository" API (in Level 2 or 3)
would help, e.g., we could define a "copySubtree" method that would copy
Nodes from one implementation to another.  I had conceived of this as "read
from a repository to an application" or "write from an application back to
a repository", but maybe in the general case we're just copying from one
DOM implementation to another.  Are there other such operations we should
be thinking about? Alfie, this takes us back to square 1 with your
question; do you have something to suggest that would make your life easier?

Mike Champion

At 10:58 AM 3/10/98 -0500, Gavin Nicol wrote:
>>>Thanks a lot for the reply. My point is really that DOM nodes
>>>may contain nodes from different implementors, correct? 
>>
>>This question keeps coming up, but I don't really understand the scenario:
>>You're writing an application and exposing the DOM as its API; how will
>>you get nodes from different implementors in YOUR application?  Forgive
>>me if I'm missing something obvious here ...
>
>In JAVA, this would be trivial (in fact, even in C++). For example,
>I have DOM implementation that read DynaText books, and use SAXDOM
>to pull in an XML document I want to transclude into the ebook. Here
>we'd have 2 different implementations with two very different sets
>of performance characteristics.
>
>This is also the *exact* scenario I was talking about with identity:
>
>   1) I have a C++ implementation of DOM that exposes DynaBase
>      documents.
>   2) I use SAXDOM (via a C++ to Java gateway) to read an
>      XML document in.
>
>If I then transclude either of these into the other (using native
>methods in JAVA, and a C++ --> JAVA gateway), checking for identity
>with language specific mechanisms is unreliable.
>
>
>
Received on Tuesday, 10 March 1998 13:22:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:44 GMT