Re: Comments on DOM 2

Several months ago I raised the following question:

> >
> > COMMENT ON § 1.2.
> >
> > IMO the createDocumentType method should be placed in the Document
> > interface, since a DocumentType node is considered a child node of a
> > Document node.  It has to be inserted into the document tree, because
> > its position in the XML Document is not fixed as the follwing example
> > shows:
> >
> > <?xml version = "1.0" encoding = "UTF-32" ?>
> > <!-- comment 1 -->
> > <?ProcessingInstruction ... ?>
> > <!-- comment 2 -->
> > <!DOCTYPE ... >
> > <!-- comment 3 -->
> > <!-- comment 4 -->
> > ...
> >
> > So it would be better to treat it like every other node which can be
> > part of the document tree.
> >
> > Therefore, also the createDocument method of the DomImplementation
> > interface should not contain any doctype parameter. Instead, the
> > application should be responsible for creating a Document Type node with
> > the above suggested method of the Document interface, and add it to the
> > child nodes of the Document node which created it.

Arnaud Le Hors answered:
> We've actually debated this over and decided otherwise. The reason is
> that this would mean one would first create an untyped document and then
> sets its type by inserting a DocumentType node in it. And possibly
> change it again at any given time.
> However, changing a document type can have a huge impact on the
> document, since it impacts entities and default attributes. For that
> reason the type of the document is immutable and as to set at the time a
> document gets created. Which is why the DOM interfaces have to be the
> way they are.

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.  For example you are using a processing instruction to generate a
DTD "on the fly".  This DTD is stored in a file while the Doctype
definition of your document is pointing at that file.  (BTW:
Generating a DTD on the fly is not as peculiar as you might think. 
Exactly that is being discussed at the Text Encoding Initiative, TEI,
to meet the needs of scholars for adjusted DTDs.)  Then it makes a
difference if you have

<?xml version = "1.0" encoding = "UTF-32" ?>
<?ProcessingInstruction ... ?>
<!DOCTYPE ... >


<?xml version = "1.0" encoding = "UTF-32" ?>
<!DOCTYPE ... >
<?ProcessingInstruction ... ?>

Therefore it is incorrect to write: "The Document interface represents
the entire HTML or XML document" (§1.2.:"Interface Document").  In the
case of an XML document it represents only the document tree starting
with the root element.  So we are in need of another element, that
contains the whole XML document and has an ordered list containing the
xml-declaration, processing instructions, a doctype definition and the
document node.  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. 
Whether this means, that the createProcessingInstruction method should
be moved out of the document interface or could remain there too,
needs to be discussed.

 Dieter Koehler, M. A. -
 Mittlere Kaulberg 22, D-96049 Bamberg, +49(0)951-5190726
 "": 1000+ Philosophie-Links
 "": Deutsche Philo-Links
 "": Open XML - XML-Komponenten fuer Delphi

Received on Saturday, 26 February 2000 12:48:48 UTC