W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2007

Changing xmlns attribute on the fly.

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Mon, 6 Aug 2007 14:45:55 +0100
Message-ID: <e72b1b360708060645q1b84467fp32faf04091e5f5be@mail.gmail.com>
To: www-dom@w3.org

Hi all.

Some ecmascript+dom implementations (aka, web browsers) allow this
statement to be executed


where node is an DOM Element.
What they do, I don't know, nor I expect for such behaviour to be
defined, since the specification
does not mention everything in this regard.

I see only two possible outcomes: either an exception is throw or the
DOM tree has to be rebuilt at runs time.
Imagine the possible scenario:

So that means you can change the default namespace on the fly, and of
all children that depend on it, which obviously must change their DOM
interface, their rendering and so on.
You have an element with nodeName object, with data and type properly
set to show some external content, in a xml document, in the default
namespace http://foo.com/, and all the sudden you change xmlns of its
parent to http://www.w3.org/1999/xhtml. What should happen ?
The only solution I can think of, is to rebuild the DOM tree,
reinitialize everything, and so on, while keeping all custom data,
ecmascript properties of the tree nodes, and references.
What I mean with references is something like this

var docum = //get document reference, with default namespace !=
var node_1 = docum.getElementById('some_id');

And by now the namespace has changed and node_1 must still point to
the same node instance, unless you find a mechanism to change the
memory address somehow.

All the processing is comparable to the renameNode method, with the
extra load of having to parse the entire tree, due to the default
namespace change. I'd rather have an exception thrown.. it's easier
for the implementers.

Thank you.
Received on Monday, 6 August 2007 13:46:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:13 UTC