Re: [xml-dev] what's special in XMLNS attribue .?

[Ronald Bourret <rpbourret@rpbourret.com>]

David Brownell wrote:
> 
> It's not clear to me how removing "xmlns" attributes would
> have anything at all to do with renaming.

The original question was:

"I'm trying to remove XMLNS attribue from this XML : 
<path xmlns="http://schemas.xmlsoap.org/rp/"
se:mustUnderstand="1"></path>

By using :
IXMLDOMNamedNodeMapPtr m_NodeMapPtr=m_Obj->Getattributes();
IXMLDOMNodePtr RemovedNode = m_NodeMapPtr->removeNamedItem(L"xmlns");

The removeNamedItem successeded but the the attribute remained."

The next question was, "how can i implement the make all elements and
attributes belong to no namespace". Thus, the question is effectively as
follows:

How do I change this:

   <path xmlns="http://schemas.xmlsoap.org/rp/"   
se:mustUnderstand="1"></path>

to this:

   <path se:mustUnderstand="1"></path>

using the DOM?

In other words, how do I rename an element from
{http://schemas.xmlsoap.org/rp/}path to path with the DOM?

> DOM binds namespace URIs "early" ... which means that the
> name isn't going to change no matter what any "xmlns" attributes
> say.  Move a DOM node to some other part of the tree, and
> the namespace URI doesn't change even if the prefix used in
> its node name is bound to a different URI.

We're in agreement here. That is why I pointed out that the question was
really one of renaming an element/attribute, rather than removing an
xmlns attribute. Since element/attribute names are read-only, the only
way to do this with the DOM is to create a new node and copy all of the
information over by hand.

> Or did someone change DOM to be "late binding" when
> I wasn't looking?

Nope.

> If there's anything in the DOM spec that says "xmlns"
> attributes should get special treatment, I surely don't
> remember it.  Seems like some DOM implementation
> has a conformance bug.

The only possible bug is whether it is correct for
NodeMap.removeNamedItem to succeed when called for an xmlns attribute.
The DOM spec doesn't directly address this case, so it's not clear what
the correct behavior is.

-- Ron