W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1999

Comments on DOM 2

From: Dieter Köhler <dkoehler@ix.urz.uni-heidelberg.de>
Date: Wed, 01 Sep 1999 20:00:25 +0200
Message-ID: <37CD69B9.8BDD0998@ix.urz.uni-heidelberg.de>
To: "www-dom@w3.org" <www-dom@w3.org>
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.


COMMENT ON § 6.1.1.

If an iterator must behave "gracefully", it had be informed about any
modification of the document structure immediately after that happend. 
Therefore, an iterator should be bound to the Document node that created
it by an iterator list.  When an insertBefore, replaceChild,
removeChild, or appendChild method of a node is called the node informs
its owner document node that its structure had been changed, the owner
document then updates every in its iterator list registered iterators
which is effected by the structure modification.


COMMENT ON § 6.2.

a) Why not implement a FirstNode method and a Root attribute in the
NodeIterator interface, since such a root is used in the
createNodeIterator method of the Document interface?  

b) What about a LastNode and a PreviousNode method?

c) For programing convenience it would be better to use a set of
NodeType constants to determine 'whatToShow". A Delphi implementation of
the DOM, for example, can easily define such a set and a constant for
'show_all' by

type
  NodeType = (Element_Node, Attribute_Node, ..., Notation_Node);
  WhatToShow = set of NodeType;
const
  show_all: WhatToShow = [Element_Node .. Notation_Node];

A TreeWalker or Iterator can then very easily determine whether a node
should be accepted or skipped (in the following example FWhatToShow is
an instance of WhatToShow):

function TreeWalker.parentNode: Node;
begin
  ...
  if not (Result.NodeType in FWhatToShow) then {skip node}
  ...
end;


ADDITIONS TO THE CORE INTERFACE

I programed an open source implementation of the DOM 1 in Delphi 3 which
can be found at "http://www.philo.de/xml".  To improve the functionality
of the implementation I added several procedures and functions to it. 
Everybody interested can download the package which includes a detailed
manual in English (the initial HTML page had not yet been translated)
and its full source code.  This implementation contains also several new
types of nodes to build a complete tree for any internal DTD.  Also
included is a component for transforming an XML file into a DOM tree
simultaneously testing it for well-formedness. The ability for parsing
external entities had not yet been implemented.

Beside the routines for building a DTD tree the most interesting of my
additions IMHO is a property Code to the Node interface which returns
the corresponding XML-code of the node and all its children.  Thus,
transforming a DOM tree back to an XML document is very easy, because
you can use the Code property of the Document Node which recursivly
calls the Code property of its children.  Here is the code of the Delphi
implementation for the Node interface (named 'TdomNode'):

TdomNode = class
...
public
  property Code:            WideString       read GetCode;
...
end;

implementation

function TdomNode.GetCode: WideString;
var
  i: integer;
begin
  Result:= '';
  for i:= 0 to ChildNodes.Length -1 do
    Result:= concat(Result,ChildNodes.item(i).Code);
end;
 

=====================================================================
 Dieter Koehler, M. A. - dkoehler@ix.urz.uni-heidelberg.de
 Huehnerstein 1, D-69121 Heidelberg, +49(0)6221-474359
 "http://www.philo.de/Philosophie-Seiten": 1000+ Philosophie-Links
 "http://www.philo.de/VirtualLibrary/14.de.htm": Deutsche Philo-Links
 "http://www.philo.de/xml": Open XML - XML-Komponenten fuer Delphi
=====================================================================
Received on Wednesday, 1 September 1999 14:02:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT