W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2000

Re: Namespace treatment, cloning and node.supports

From: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>
Date: Mon, 06 Mar 2000 15:51:28 +0100
Message-ID: <38C3C5F0.25AFE557@ppp.uni-bamberg.de>
To: "www-dom@w3.org" <www-dom@w3.org>
> > .. or if one wants to write a component which interacts with other
> > people's components in handling DOM trees.  One does not know, whether
> > the other peoples components use the old DOM1 methods for creating
> > attributes or the new namespace methods.
> ?
> This situation perplexes me. Isn't it the same as when one has a 3-D
> geometry model and then is perturbed when some app is permitted to
> insert 2-D elements into it? Either the model is prepared for this and
> the 2-D instances comply to a 3-D interface, or one had better not
> subsequently try to perform perspective transformations on the model.

The problem with this analogy is that as you described it, if I
understand it correctly, the 3-D model is a consistent extension of
the 2-D model.  But the behavior of the namespace-aware and
non-namespace-aware model is not.  To extend your analogy:  It is
similar to using for the 2-D model polar coordinates and for the 3-D
model cartesian coordinates and storing the information in the same
variable.  What I only recommend is storing the information what
system of coordinates is used somewhere in the data set.  That's no
big thing and would make some other things a lot easier.

> If there is a prospect of "non-namespace-aware qualifiedName conflict",
> then the "nna" app will need to provide sufficient information for the
> "na-model" to provide it with unambiguous results. It is possible to do
> this statically. In which case the "qualifiedName conflict" is a
> serialization artifact, or rather a consequence of conflating
> serialization and DOM state.

Whatever strategy you use to overcome such a conflict it must be
unambiguous in every DOM tree, that means independent from any
serialization, in order to allow the distribution of
application-independent components.

 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 Monday, 6 March 2000 09:52:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:28 UTC