DOM - Creating Documents

[Leigh Dodds]

> It's hard to guess what the original motivation was, and I have never
> been a member of the DOM WG (and joined the IG fairly recently), but I
> do think that it makes some sense: after all, the DOM will often be an
> adapter interface to an entirely different structure, like a set of
> database tables, and in such a contexts, createDocument might not make
> sense at all.  Now, that said, it would be possible to have
> createDocument simply throw an exception when it's inappropriate.

Granted, the actual implementation of the DOM tree may be very different
to the representation as defined in the spec, but this still doesn't
preclude the creation of a new Document object. After all I don't care
*how* its created, I just want to deal with it in the same way as I
would any other document. That representation wouldn't get passed
to another parser it would all be handled internally.

What I find puzzling is that I can createElement, createAttribute, etc, etc
and then...what? Lose the changes? Basically if I can create the
different node types without having to worry about implementation
details, why can't the same be applied to the Document. If the
implementation
was actually database tables that shouldn't matter - I can create an
Element,
but not a Document - seems a huge whole to me - otherwise why would I bother
creating elements anyway: they only persist for the period of
my application. Useless if I want to save those changes, or build up a
new structure from scratch.

Yours Confused,

L.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)