(unknown charset) Re: removeAttribute

On Fri, 17 Mar 2000, Dieter [iso-8859-1] Köhler wrote:

>> Generally, removeAttribute is used when a user does not already have
>> a reference to the node and, hence, will not be reusing it.  Otherwise
>> the user could have called removeAttributeNode.  But removeAttribute
>> still allows for reuse, since it does not explicitly delete.  If the
>> user hung on to a reference in some prior call, then it does not get
>> deleted.
>
>So what's the reason, why removeAttribute does not return the
>attribute's reference?  If des user does not already have a reference
>it might be useful and convenient that he might have it afterwards.

The NamedNodeMap version does return a node.

But for this usage, it is more likely that he does not want it.  Any
method which returns an object forces every COM caller of that method 
to explicitly unreference the return.  Only Java or other garbage-
collected bindings can simply ignore it if they don't want it.

Also, a number of implementations do not create full attribute nodes
unless they are explicitly asked for.  Making this method return a
node would force all implementations to construct an attribute node,
whether it was needed or not, and would force all reference-counted
implementations to call a dereferencing method, whether the node
was needed or not.  Implementations which want the node for some
reason can use the Node-based methods instead of the name-based
methods.

>BTW: If the applications mixes namespace and non-namespace methods for
>adding nodes in the following code
>
>MyAttr:= MyElement.getAttributeNode('xyz');
>MyElement.removeAttribute('xyz');
>
>the first line might return another node than the second removes.

Section 1.1.8 states:

"Note: DOM Level 1 methods are namespaces ignorant. Therefore, while 
it is safe to use these methods when not dealing with namespaces, 
using them and the new ones at the same time should be avoided. DOM 
Level 1 methods solely identify attribute nodes by their nodeName. On 
the contrary, the DOM Level 2 methods related to namespaces, identify 
attribute nodes by their namespaceURI and localName. Because of this 
fundamental difference, mixing both sets of methods can lead to 
unpredictable results. In particular, using setAttributeNS, one can 
set on an element two attributes (or more) that have the same nodeName, 
but different namespaceURIs.  Calling getAttribute with that nodeName 
could then return any of those attributes. The result is implementation 
dependent. Similarly, using setAttributeNode, one can set two attributes 
(or more) that have different nodeNames but the same prefix and 
namespaceURI. In this case getAttributeNodeNS will return one or the other, 
in an implementation dependent manner. The only guarantee in such cases, 
is that setAttribute and setAttributeNS affect the node that, respectively, 
getAttribute and getAttributeNS return."

Perhaps it should extend to describe the following sets instead of just
the simple string-based get/set:

getAttribute
getAttributeNode
getNamedItem
setAttribute
setAttributeNode
setNamedItem
removeAttribute

getAttributeNS
getAttributeNodeNS
getNamedItemNS
setAttributeNS
setAttributeNodeNS
setNamedItemNS
removeAttributeNS

Ray Whitmer
ray@imall.com

Received on Monday, 20 March 2000 11:37:22 UTC