Re: Comments on DOM 2

Dieter's asked some very good questions. I don't think we have answers yet.


>For the time being this convinced me, but in reconsidering the issue I
>was beginning to have doubts, because there is still the problem, how
>to represent processing instructions outside the root element in the
>DOM.

There are ways to handle this, though they're not elegant. One is to
temporarily store the pre-doctype PI outside the DOM, and create/insert it
after the DocumentType and Document have been instantiated. Another is to
create a dummy document to retain the pre-doctype nodes, then import them
when the "real" doctype becomes available.

The problem here is that some folks want to be able to adjust their DOM's
behavior based on which XML-based language is being processed -- which
means they need to make this decision based on the DTD or schema.  The
standard object-oriented approach to this would be to select different
subclasses of the DOM for these different behaviors... but that decision
would have to be made no later than the object's constructor. And since
most of the factory methods are on the Document, that means that
constructing the Document  becomes the decision point.

If you're willing to go with a switch or proxy solution, that decision
could be postponed. Switches would probably impact a considerable amount of
the DOM code and be hard to extend; proxies yield an extra layer of
call-and-return overhead (though perhaps only on the Document itself).

Postponing the decision has other issues. If you can change the doctype
after you've started creating nodes, you risk having the earlier nodes not
be subclassed as expected... which means either going through and replacing
them (what if the user has a persistant reference to one?) or dealing with
the mismatch somehow.


>The methods for creating a Document node or a
>DocumentType node should be moved out of the DOMImplementation
>interface into such a wholeDocument interface (unless we agree, that
>the DOMImplementation interface itself should be the wholeDocument
>interface I am demanding), likewise it also needs a
>createXmlDeclaration and a createProcessingInstruction method.

Straw man: What if this DOM wants to subclass PI's in one type of document
differently from those in another?

I agree that we do need to look at how one assigns and changes the DTD
after a Document has been created; that's one of the issues open against
the "Content Model" section of DOM Level 3. But the reason we postponed it
was that we weren't sure we had a good answer for the above questions. Note
that the question of _how_ the DTD/schema is bound to the Document is also
deferred to that chapter.

The question of how to handle the XML Declaration was also passed off to
Level 3; there isn't agreement yet re whether it's a separate node, a set
of additional fields on the Document node, or something else entirely. I
_think_ the "Load/Save" chapter has that on their issues list, if not,
Level 3 Core should address it.

______________________________________
Joe Kesselman  / IBM Research

Received on Monday, 28 February 2000 09:23:08 UTC