Re: Anybody for a server-DOM spec?

Claude Zervas wrote:

> The current DOM spec is next to useless for server-side
> applications.

I find this to be an overstatement.

> It contains way too much baggage designed
> for client-side scripting that only benefits basically
> two or three big vendors. It has almost no support for
> editing (since there are no defined 'set' methods for
> most of the node tree mutation attributes).

Please elaborate on what you mean here.  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.
What is a "tree mutation attribute"?

> I propose that a group of interested people get together
> to define a new spec (using the current one as a base)
> that lends itself to efficient server-side implementations
> and that can share nodes between implementations.
> It is impossible to create distributed documents with the
> current DOM because of the baffling constraint that all
> nodes must be from the same implementation and that
> node collections must be 'live'. There are quite a few
> other problems with the DOM that preclude server-side
> use as it stands.

Static lists make a potentially-large snapshot of state.  This is
usually much less efficient than getting data from the live model.  I
would be happy to demonstrate with real code, if you like.  A live
model, at worst, only needs to toss any cache when something changes,
the moral being, don't change anything until you have used  the
information or transferred it to a static place.

Live lists seem to make more sense for my server uses, but if you want
static, it is easy to write a routine that copies the live entries to
your own static list.  Or using data sharing techniques, it is possible
to efficiently snapshot the nodes through a clone operation and then
your list is as static as you like.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.

> Most of the people using the DOM for server-side applications
> are most likely creating non-conforming implementations and
> it is sad that these implementations will not be interchangeable.
> We need to come up with a basic server-DOM spec before things get
> too whacky.
> My current implementation has a switch that enables/disables
> conformance, but thats kind of silly and doesn't allow for
> a really efficient and small-footprint implementation.

There are two ways I know of to interchange pieces between different
implementations:

1.  Reconstruct the pieces using the factories of the target
implementation while looking at the oiriginal implementation through the
DOM API.

or

2.  Rigidly define the DOM that no implementation can do any optimized
implementation beyond what the simplest implementation can be intermixed
with.

I see nothing preventing anyone from doing (1) right now using existing
DOM methods, and such a technique could easily become a routine of a
standard toolset without being incompatible with DOM.  It could also be
added in a future version of DOM as a convenience routine.

If you are advocating (2), then I will oppose this very strongly.

Sure, things are missing in the current API.  I don't think anyone
believes it could be otherwise unless the spec were dictated by a single
source, and then it would be complete for that person only.

I write a conforming application that has extensions when you need
them.  You explicitly cast to a proprietary API when you need things
that cannot be reasonably accomplished through the DOM spec.  It is easy
to find the explicit castings where the DOM was not adhered to.  The
rest of the code is generic (or will be if/when the DOM spec becomes
nailed down).

You have brought up a wide variety of issues which are not necessarily
connected.  I would like to see you clarify much smaller requirement
sets instead of shotgunning the whole spec under the name "server DOM".

There are many on this list who can contribute a great deal to the
discussion of each item taken individually.  I don't want a server DOM
to be bloated by anyone.  I don't want editing requirements to be
compromised, either, in the name of a light server implementation.  It
is not a small task if done with adequate consideration and looking at
things from many points of view.  I suspect that others who happen to be
using DOM for servers and editing, may not see the issues as clear-cut
as you present them, but may wish to get into the details and real
justification.  So let's discuss!

Ray Whitmer
ray@imall.com

Received on Friday, 14 August 1998 20:57:02 UTC