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

Re: namespace treatment, 2nd attempt

From: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>
Date: Thu, 09 Mar 2000 18:56:45 +0100
Message-ID: <38C7E5DD.EF538B59@ppp.uni-bamberg.de>
To: keshlam@us.ibm.com, "www-dom@w3.org" <www-dom@w3.org>
> >Changing the prefix shall be
> >allowed whenever the current nodeName is a qualified name
> 
> I think that one's definitely wrong. The only reason we permit changing the
> prefix on a namespaced name is that it "isn't really part of the node's
> name" -- in the namespace world, the "real" name is the combination of
> namespace URI and localname. For a non-namespaced node, the prefix is an
> essential part of the node's identity and really should not be mutable.
> 
> As one practical illustration of why: Consider something like the HTML DOM,
> where different subclasses of element were selected based on the namespaced
> name. If you allow folks to change the prefix -- from postal:address to
> memory:address -- you may wind up with something that claims to be a
> memory:address but supports getZipCode() instead of getBytes().

I am getting confused:  Isn't your example about a namespace node,
where changing the prefix is allowed?  However: That is a serilization
problem for which I would suggest replacing the node instead of only
changing the prefix.

But as my last posting demonstrates, I am not convinced about my own
suggestion any longer.  What I wanted to overcome is the different
identity criteria for namespace and non-namespace nodes when using
namedNodeMaps.  Philosophically spoken it is the problem that Leibniz
called "principium identitatis indiscernibilium", the sentence of
identity of the undistinguishable, or which Quine formulated in the
claim "no entity without identity". That means, that two objects are
two objects if and only if at least one of their essential properties
is different, and on the other hand, that you need to compare _all_
essential properties in order to identify an object undoubtedly.  DOM2
presupposes, that for non-namespace nodes the essential property is
the nodename, and for namespace nodes the essential properties are the
local name and the URI. That would suggest, that a namespace node is a
different _type_ of object than a non-namespace node, since there is
no way of mapping the essential properties of a nonnamespace node to
that of a namespace node, or reverse.

To demonstrate this on an XML source code example:
Is "<a:x/>" different from "<b:x/>"? -- In a non-namespace view it is
definite that it is so.  In a namespace view it depents on to what URI
the prefix is bound.
Is "<a:x/>" different from "<a:x/>"? -- In a non-namespace view it is
definite that it is not so.  In a namespace view it depents on to what
URI the prefix is bound.
So mixing the two approaches is insufficiant, since if the one thing
is definite the other is contingent, which leads to a loss of
information if one proceeds from the one relation to the other: Let
'=' be the non-namespace identity relation and '~' be the namespace
identity relation, than from "a=b" follows "(a~b) or not (a~b)", and
from "(a~b) or not (a~b)" follows "(a=b) or not (a=b)".  That
demonstrats that in moving from one relation to the other information
about the object gets lost (in XML documents this is compensated by
the fact that the namespace information might be spread over several
other tags, so that two documents might be identical as a whole in a
namespace view, even if non of their elements are identical in a
non-namespace view).  Therefore it is not by accident, that we get
problems if we try to use the same method to identify both types of
objects.  It is only by chance, if we get the object which we set with
the one method back with the other.

Therefore my main goal is to convince you, 
1. that the current DOM2 is not backward compatible
2. that the current DOM2 is not in itself coherent
3. that this has to be faced not only in the documentation, but in the
API itself.
The other things are only more or less good proposals to overcome this
situation.

-- 
=====================================================================
 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 12:58:21 GMT

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