Re: Namespace treatment, cloning and node.supports

In thinking about the problem I described in my last posting to this
threat, I found that the DOM1 methods must not entirely be replaced by
the namespace methods, because one might want to use the DOM on an XML
document which is not namespace conformed (which uses e.g. a tag like
<a:b:c/>) (e.g. using createElementNS('','a:b:c') would raise a
NAMESPACE_ERR because 'a:b:c' is not a wellformed qualified name).  So
a general method for reading an XML document in DOM3 has to be built
on the old DOM1 methods unless something totally new is introduced. 
If one wants later on apply namespace methods the whole document has
to be transformed by using namespace methods in order to avoid
conflicts.  That seems to me rather complicated.  I am raising this
question now and not after a DOM3 draft had been presented, because I
think the duality of both methods to be still a problem in DOM2 and
when we go on to DOM3 people could say: "We cannot have better
solutions, for withdrawing the duality we introduced in DOM2 is not
consistent with our policy."

As I described earlier the unconnected existence of namespace and
non-namespace methods side by side in one API makes it almost
unpossible to write fast application-indepentend reliable components,
because the DOM documentation says that the application is responsible
not to mix both kinds of methods on one document, but does not state
how to represent the decision which kind was used in the document and
how to communicate this decision between components or applications
which have to work together.  Imagin a component A for displaying
*any* DOM tree on a computer's screen that was presented to it from
some other component B which used the same API.  In an OO view
everything what is internal to one component is hidden to the other. 
Since the API allows both kinds of methods Component A cannot be sure
what kind of methods had been used by component B to create the entity
and attribute nodes in order to use the aprobriate ones for
retrieval.  Such tests might be very time consuming.  So one writes
components which neglect such tests.  And because the API raises no
exceptions when both methods are mixed there is an considerable amount
of danger, that in using different components, which handle such tests
sloppily, you will get instable application which might be not obvious
at first sight.

So here is a suggestion how to fix that problem:  One could use a
namespaceBehavior flag on the document and documentFragment interface
which has the three possible values 'uses_namespace',
'uses_no_namespace' or 'unspecified'. 'unspecified' is the default
value.  The first time one calls a "problematic" methods this flag is
set to either 'uses_namespace' or 'uses_no_namespace'.  If later on a
"wrong" method is called an exception is raised.

In the example above component A must only examine the
namespaceBehavior flag in order to find out which methods it is
supposed to use, and a wrong choice of a set- or remove-method is
immediatly punished by raising an exception.

-- 
=====================================================================
 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 Sunday, 5 March 2000 18:16:29 UTC