Re: Anybody for a server-DOM spec -> transferring nodes and listener model.

Claude Zervas wrote:

> It is impossible to implement Node.append/insertChild() etc. without
> casting the Node argument to a known implementation. Otherwise,
> how would you set the parent and next/previousSibling attributes
> of the new child?  Casting is slow (in Java) and it assumes a homogeneous
> implementation.

It is a simple virtual function.  The implementation supplies the
functionality, and the base class provides the API -- no expensive upcasting
involved at all.  OO languages would be in big trouble if you had to upcast
every time you wanted to implement this type of a function.

> What if I'm using remote objects and all I can
> count on is the Node interface?

Then it is not DOM compliant.  But creating proper proxies for a DOM would
involve proxies that upcast properly even remotely.  There is no reason I
can think of to create only a Node proxy for an object that is a DOM Element
interface elsewhere.

> Do I need to clone the new node
> and its children ? What if the new node is a remote object whose
> children may change dynamically and the root document needs to
> reflect that? There is no support for adding observers, which would
> be a way to do this. There is little support for MVC in general
> in the DOM. Multiple views may share the same DOM tree but there
> is no defined way to attached oberver views to a DOM in order to
> dynamically update the view.

The need for observer support is clear in DOM.  But I believe that nodes of
a particular Document hierarchy should be part of the same implementation,
which could be distributed in nature.  To bring in nodes from other
hierarchies that may live in incompatible schemes, it is necessary to
reconstruct the node to be transferred.

> It should be possible for an editor to edit a remote document
> without cloning the entire tree locally. The editor should make
> no assumptions about the implementation of the remote DOM, since
> it may be from a different vendor.

Yes.  My implementation makes this quite practical using the current APIs.
The elements may, for example, live in a database, and be lazily loaded and
updated as they are modified.  I will be hooking it up to a database soon,
and the dependancies are structured such that you should be able to edit an
encyclopedia-sized document over a modem connection, and never wait
(assuming the server did the parsing, because parsing will happen
sequentially at some point).

> Well, what if the document itself is distributed? Not all the
> nodes may be on the same physical machine. All I can count
> on are the primary DOM interfaces. You are assuming a fairly
> simple document server whose references are all local. What if
> you are using CORBA or Voyager ? What if the clients expect
> a remote reference to a document tree and not XML text?

That is fine for an implementation that is designed to be distributed.  But
I still don't believe that multiple implementations should be intermixed in
the distributed document case (except in the case of specific
implementations that are designed to work together as a single
implementation, or as a common more specific distributed API is identified).

> Again, this sort of casting is not possible in a distributed
> object environment.
> You cannot assume all objects are local. You can't just clone
> huge documents (say 10MB) to get around this either without
> incurring huge runtime costs. If I've got a shared document
> it should stay shared... What if the original is modified,

I never assumed they were all local.  Only that all documents in a
particular document hierarchy will share the same implementation,  whether
that be local, remote, or mixed.

In some cases, transporting between documents will keep the parts shared if
the implementations are compatible.  In others, they will not and can not,
in which case there must be a process to bring the data into the
implementation.

> then do all the clones need to be updated?

The DOM currently defines no explicitly-shared relationships.  All sharing
as well as cloning gives every user unique control over any incorporated
children.  In the case of sharing, this means that the context must detect
when something that is shared is being modified in a specific context, and
replace it only in that context to make it behave as though it were not
shared.

Requirements for explicit sharing with mutations that affect globally must
be identified so that APIs can be constructed, where that is desired.  To
have changes affect hierarchies globally due to sharing which is hidden
would be unacceptable.

> Also, what if I decide to go with a different DOM implementation library.
> You are saying I would need to rewrite portions of
> my applications just to accomodate the new proprietary API...

I only suggest that proprietary APIs can be used to great advantage until
common APIs can be established.  But good APIs will not happen overnight,
and there are good techniques for using the standard wherever appropriate,
and explicitly flagging where yet-unstandardized functionality is accessed.

The "helper" function I suggested for moving data between implementations is
not really proprietary since it can easily be made completely generic so
that it will work in any implementation, and also so that it can favor a
specific known implementation with certain requirements for transferring
between documents.


> Unless I'm really missing something basic it just seems like
> there is still some work to be done before the DOM can be
> really usable in server-side applications. I would rather
> not depend on my own or anyone else's proprietary APIs...

We all would rather not depend upon proprietary APIs.  But we will not get
there overnight, and anyone who claims to produce such an API overnight will
isolate themselves in a proprietary corner, calling it an "open" standard,
but with not enough concensus to be open.

> Given the distributed nature of the Web it seems only logical
> that the DOM itself be flexible enough to be used in a distributed
> fashion. Maybe someday it won't even be necessary to convert
> a DOM tree to XML/HTML for browser clients to access and render
> a document. Documents are not necessarily atomic, and could easily
> be spread over multiple physical sites. The DOM should be able
> to be used this way.

Agreed.  I will be doing this very soon.  But, I will not expect a
document's nodes that came from a database to be freely intermixed with a
document's nodes which came from a local parser without going through some
type of transfer function which now causes the nodes to live in the same
type of setting, i.e. a distributed database, as the rest of the nodes of
the document.

> Much of the current work is driven by the classic idea of client
> XML/HTML browsers connected to an HTTP server that has local access
> to all its documents. Granted, this is the most common use, but
> things change quickly and in my perhaps-not-so-humble opinion
> the future lies in dynamic fully distributed document objects.

I agree.  I do not see what has been done up until now as incompatible with
that greater vision of dynamic objects.  I will be doing lots of extensions
and working as hard as I can to get the appropriate extensions built into
future standard APIs, while living within the DOM that is specified today.
I see nothing in the current DOM that needs to be discarded, except that I
might discard entity support for servers.

> The DOM is the perfect place to start.
>
> >...  So let's discuss!
>
> ok!

OK.  Let's talk about new hypothetical functions.

How about starting with a standard function for transferring nodes from one
implementation to another:

Node newNode = myDocument.transferNode(oldNode);

When the implementations are compatible, newNode is merely removed from any
parent assigned to the new document as an owner, and returned.

When the implementations are incompatible, the newNode is a clone of the
oldNode using the document's factories and ownership, and the old node is
not only removed but also destroyed inasmuch as is possible in garbage
collected implementations.

To what extent does this solve your concerns transferring between
implementations?

Then, we could move on to a listener model.

How about registering on a node zero to many change listeners which are
called back whenever content (aka data or children) or attributes are
modified?  What else do we need there?  Under what circumstances should
unhandled change events be propogated upwards in the hierarchy?  What would
your ideal API look like?

I think two items is enough to discuss at a time, but if you have a higher
priority, we can shift.

Ray Whitmer
ray@imall.com

Received on Monday, 17 August 1998 13:53:31 UTC