- From: Dieter Köhler <dieter.koehler@ppp.uni-bamberg.de>
- Date: Thu, 09 Mar 2000 18:56:45 +0100
- 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 UTC