Namespace treatment, cloning and node.supports

(1) In my opinion the prefix attribute of the node interface should be
readonly in DOM2, since changing the prefix should also effect the
namespaceURI, but the DOM2 provides no way to alter or to calculate
it.  Instead of changing the prefix the DOM2 should prescribe to
remove the node and to replace it by a new one.

(2) §1.1.7.Note reads: "... using setAttributeNS, one can set on an
element two attributes (or more) that have the same nodeName ..." 
That would lead to a violation of the XML conformance of the document,
since the nodeName represents the qualified name which has to be
unique. This also effects the setAttributeNS and setAttributeNodeNS
method of the element interface, e.g.:


would result in a malformed document without raising any exception. 

Therefor I would suggested leaving the treatment of namespaceURIs to
DOM3 which I hope to have some routines to check a document for
namespace conformity and to compute the right namespaceURIs even in
the case of namespace inheritance.  Instead localNames and prefixes
can easily be determined by analyzing the nodeName of an element or
attribute node.  The old DOM1 methods should be used for creation, and
the element and attribute node should get a namespaceURI attribute
which is both, readable and writable.  So since the DOM2 has no
testfor namespace conformity of the whole document, everything related
to that should be left to the application. Instead the DOM2 routines
should concentrate on guaranteeing the XML conformance of the

(3) node.cloneNode: Cloning an unspecified attribute node should
return a specified attribute node, shouldn't it?

(4) node.supports: Since this is very similar to
DOMImplementation.hasfeature, why not use the same word?

 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 Tuesday, 29 February 2000 10:56:06 UTC