W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2000

Re: How can I put a DocumentFragment in a Document?

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Tue, 21 Nov 2000 09:36:53 -0500
To: Claude Zervas <claude@utlco.com>
Cc: <www-dom@w3.org>
Message-ID: <OF7C9AE938.844326E6-ON8525699E.004DEAE9@pok.ibm.com>

>>... Remember that nodes belong to
>>specific Documents, and may only be appended to that Document.

>This is a very unfortunate design constraint that makes caching document
>fragments in a templating environment fairly inefficient.

Unfortunately, the fact that  different (and incompatable) DOM
implementations may be in use within a single application -- or
incompatable subclasses of a single DOM implementation, for that matter --
required that nodes not be guaranteed to be directly transferrable from
Document to Document. That's one of the downsides of writing an Interface
rather than a specific set of classes.

DOM Level 3 is considering adding an "adoptNode" operation which will
provide a partial escape from this limitation. adoptNode will move a node
from one Document to another if the implementation judges that this can be
done safely. It would _NOT_ be guaranteed to succeed in all cases -- or
even to succeed in the same cases for one DOM that it does for another --
and if it fails the user has the responsibility of deciding how to recover
(via importNode or whatever else seems appropriate). But it would partly
address this efficiency concern without excessively constraining DOM

There's also some work starting on "embedded DOMs", which hopes to address
the question of how one can intermix trees from different implementations.
My own guess is that full DOM behavior can _not_ be maintained across those
transition points, and that programmers will have to be aware of the
relationship between the main document and the "alien" subtrees... but
we'll see what happens as the design progresses.

Meanwhile, the easiest way to avoid "needless cloning" is to avoid creating
more Documents than are required. For example, when merging XML files what
I've sometimes done is parse the additional files as SAX streams, then use
that to drive a DOM tree builder that creates nodes within the context of
my main document rather than a completely new one. The resulting tree can
then be merged with the host document with no special effort.

>encourages bloated implementations (Xerces 1.2 is 1.5 megs!)

Uhm... There's a lot more to Xerces than the DOM, remember.

And there's a tradeoff between codesize and model size. The XML4J 2.x DOM
took only about 30K of codespace (10K zipped), since it was originally
designed for use in applets and the like... but the current Xerces DOM,
while taking more code (even ignoring the new features), takes less memory
for the actual document model.

Also, remember that different DOMs are optimized for different things. I've
written a DOM subset (the Xalan DTM model) which takes only sixteen bytes
per node. Admittedly, DTM isn't mutable, and doesn't implement Level 2 --
but those could be solved, with some work. The downside is that DTM is
heavily deoptimized for performance of operations which weren't needed for
my application.

The DOM is just an API. Pick the implementation that suits your

>creating a parallel spec for server-side or thin-client applications.

Nobody was ever able to define what operations should or shouldn't be kept
in a server-side DOM; our conclusion was that there seemed to be several
_different_ subsets that people wanted. The general question of a reduced
DOM is still on our open issues list, and will be reconsidered if/when we
can assemble a set of usecases that define a clearly useful design point.

For example: One possibility we've considered recently is a better
definition of a "read-only" DOM subset... either a true subset (which could
not throw exceptions when written to since that would change the method
signatures) or subclasses (which could enforce immutability, but would
require implementation of methods that do nothing _except_ throw
exceptions). It isn't a top priority right now, but it's still simmering on
the back burner.

The DOM is still evolving. If you have specific requirements/requests --
and even better, if you have practical usecases illustrating what problem
you're trying to solve, so we can consider alternatives -- please let us

(That's too wordy to be a FAQ entry, isn't it.)
Received on Tuesday, 21 November 2000 09:37:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:07 UTC