Re: namespace treatment, 2nd attempt

D.K. > getNamedItem
D.K. > Retrieves a node with the specified name and with a
namespaceURI that
D.K. > is an empty string or null.  If there is a node with the
specified
D.K. > name, but a non-empty namespaceURI it returns null.
> 
> This would break backwards compatibility with DOM Level 1. Consider the
> case, where a DOM Level 1 (i.e. namespace unaware) application processes
> a document with namespaces in it, on top of a DOM Level 2
> implementation. The implementation namespace aware parser creates all
> the nodes with their apropriate namespaceURIs. All of the application
> calls to getNamedItem then fail.

Good point.  But here is an example were both suggestions (the DOM2
draft and mine) fail to get complete backwards compatibility. 
Consider the following DOM1 code:

for i:= 0 to attributes.length-1 do begin
  myattr1:= attributes.item(i);
  myattr2:= attributes.getNamedItem(myattr1.NodeName);
  myattr3:= attributes.getNamedItem(myattr2.NodeName);
end;

If we have double localnames with different namespaceURIs in the map
myattr1 might be different form myattr2.  When writing your DOM1 code
this was not predictable, since the setAttribute method would have
forbidden it.  So you have no backwards compatibility either.  

Using my strategy myattr2 might be null and therefor raise an
exception on the myattr3 line.

So I am now convinced, that we cannot have an easy compatibility,
since the architecture of the map is intransitive with regard to the
getNamedItem respectivly getNamedItemNS and the item method.

So if backwards compatibility at all is an unrealistic goal in this
particular case, why not strive for a consistant DOM2, now?  That
means to raise exceptions if namespace and non-namespace methods were
used at the same namedNodeMap (a variant of a previous suggestion of
mine).  In the example above using DOM1 together with DOM2 code would
result in an exception.  Pure DOM1 code would still be able to work
together with a DOM2 API, but a mixture would be forbidden.  That is
the only amount of backwards compatibility within reach.

-- 
=====================================================================
 Dieter Koehler, M. A. - dieter.koehler@ppp.uni-bamberg.de
 Mittlere Kaulberg 22, D-96049 Bamberg, +49(0)951-5190726
 "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 Thursday, 9 March 2000 08:20:19 UTC