- From: <keshlam@us.ibm.com>
- Date: Thu, 9 Mar 2000 08:53:57 -0500
- cc: "www-dom@w3.org" <www-dom@w3.org>
Quoth Dieter: > For Attributes set by the non-namespace method the namespaceURI is > supposed to be an empty string or null, and if the Attribute's name is > namespace conform it shall be treated as if it were set by the > namespace method, e.g. setAttribute('a:b') would have the same result > than setAttributeNS('','a:b'), what means that the prefix is 'a' and > localName is 'b'. The DOM Working Group did consider this alternative, but after debating it the vote was that prefix and localname are not defined for non-namespaced nodes and should not be provided. I'm not really delighted with that decision -- it means that code may have to do an "if localname non-null use that, otherwise use node name" test -- but I think I can live with it. >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(). >(if those would not convince anybody I must be >quiet for the next month for not to become the reputation of a great >namespace troublemaker :-) Don't worry about it. You're asking exactly the same kinds of questions that were most difficult for us during the design process, you're explaining your concerns clearly, and you're suggesting fairly reasonable alternatives. We may or may not not agree that the alternatives are better, but having someone read and think about the spec this carefully is very helpful! If nothing else, it suggests that we may want to document the rationalle behind the namespace design. ______________________________________ Joe Kesselman / IBM Research
Received on Thursday, 9 March 2000 08:54:20 UTC