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

At 06:36 AM 11/21/2000 , Joseph Kesselman wrote:
>...
>DOM Level 3 is considering adding an "adoptNode" operation
>...
>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....
>
>Meanwhile, the easiest way to avoid "needless cloning" is to avoid creating
>more Documents than are required....
>... 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.

This is so, and I've done the same thing. I was mainly commenting on the importNode method, but it sounds like this will be solved to some degree by adoptNode.
What I don't understand is why the concept of "owning document" in the first place, if the WG meant "owning implementation" why not say so?  It would have been much more straightforward to eliminate the owning-document constraint and instead just state that nodes must be from the same _implementation_ and hoist the node factory methods out of Document and put them in DOMImplementation.  WRONG_DOCUMENT_ERROR would be WRONG_IMPLEMENTATION_ERROR instead, or just simply let the progammer be responsible for maintaining integrity.

>
>>encourages bloated implementations (Xerces 1.2 is 1.5 megs!)
>
>Uhm... There's a lot more to Xerces than the DOM, remember.

Yes, I was being facetious. I apologize, especially since I use Xerces quite a bit! But it is way too big for smaller client-side applications.

>...
>Also, remember that different DOMs are optimized for different things.
>...
>The DOM is just an API. Pick the implementation that suits your
>application.

This is basically translates to: "build your own". There are no published performance specs, and the API vendors don't even mention anything about what their particular implementation may be especially good at.  If you mean that we should use non-standard implementations to get the kind of behaviour we need then what is the use of a standardized API ?

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

This is good, but given the time constraints and current workload of the WG I think this is probably not going to happen any time soon. I think a parrallel discussion by non-WG DOM users would be useful and once a set of somewhat coherent usecases gets developed maybe a heads up with the WG would be in order at that point.

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

For one, I would really like to see iterators for node traversal. I was sad to see them argued out of the level one spec and could never figure out why they didn't come back in L2.

Also, an event/listener API for document/node modification notification. This is useful in MVC patterns, even on a server app. As one example, say you have a distributed cache of serialized documents (or fragments) and some controller servlets that modify some authoritative document model, any listener caches would receive notifications of the changes and refresh accordingly.

Thanks,
- Claude

Received on Tuesday, 21 November 2000 12:59:07 UTC