Re: Anybody for a server-DOM spec?

At 06:57 PM 8/14/98 -0600, Ray Whitmer wrote:
>Claude Zervas wrote:
>
>> The current DOM spec is next to useless for server-side
>> applications.
>
>I find this to be an overstatement.

Well, for starters the DOM is specified to be used only
in a single-threaded environment. This precludes all but
the most trivial server applications.

>...The big thing missing is
>editing the DTD, which is only something an advanced editor would
>tackle, and seldom on the server.  Editing generally seems to produce a
>much more bloated spec than what I consider to be server requirements.
>...

I guess I was pretty unclear. I think there needs to be a
server-DOM *and* an editor-DOM. Perhaps using "DOM-packages" like
Mike Champion's suggestions. The server-DOM would be a lean
and mean version of the DOM with support for multi-threaded
environments and mixed implementations.

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. What if I'm using remote objects and all I can
count on is the Node interface? 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.
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.

>>...
>...Perhaps you can explain why you feel
>that servers will want to mix DOM nodes from different implementations.
>If anything, the server seems like the much more homogeneous
>environment, where requests are delivered to a service in XML and that
>service will use a single DOM implementation.

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?

>... You explicitly cast to a proprietary API when you need things
>that cannot be reasonably accomplished through the DOM spec. ..

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,
then do all the clones need to be updated?
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...

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

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.

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.

The DOM is the perfect place to start.

>...  So let's discuss!

ok!

- Claude Zervas

Received on Monday, 17 August 1998 02:26:34 UTC