Changing xmlns attribute on the fly.

Hi all.

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

node.setAttribute('xmlns','http://example.com/');

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
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-F68
F082
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
!=
http://www.w3.org/1999/x
html
var node_1 = docum.getElementById('some_id');
node_1.parentNode.setAttribute('xmlns','http://www.w3.org/1999/x
html');


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.

* Joćo Eiras wrote:
>node.setAttribute('xmlns','http://example.com/');

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

I am not sure why either would happen. The DOM Core
Recommendation quite
clearly says you should not mix namespaces and
namespace-unaware methods
and setAttribute is namespace-unaware. What happens should
be clear, the
same thing as would happen if you'd used 'foo' instead of
'xmlns'. There
does not need to be an exception, nor would have this any
effect on the
namespaces in the document.

Note that especially the latter is also the case if you do
e.g.

  node.setAttributeNS('http://www.w3.org/2000/
xmlns/', 'xmlns',
'...')

which is quite legal and would not affect the namespaces of
<x/>
ele-
ments, or <y x=''/&
gt; attributes. The only way to rename elements and
attributes is through the renameNode method. Due to this, it
is possible
to create documents that are incorrect with respect to
namespaces; there
are fixup algorithms in the specification to correct such
errors e.g.
during serialization of the document.

This should all be explained in e.g. section 1.3.3 XML
Namespaces of the
Recommendation.
-- 
Björn Höhrmann · mailto:bjoernhoehrmann.de · http://bjoern.hoehrmann.de

Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de

68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Joćo Eiras wrote:
> Hi all.
>
> Some ecmascript+dom implementations (aka, web browsers)
allow this
> statement to be executed
>
> node.setAttribute('xmlns','http://example.com/');
>
> 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
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-F68
F082
> does not mention everything in this regard.
>   
[...]

Generally speaking, I believe an implementation which does
not allow
this is non-conforming.

First of all, the function you are calling is not the
version that must
be called for namespace-aware applications.  You should be
calling
node.setAttributeNS.  Thus, you might be calling this on an
XML
application which does not conform to the namespaces
specification, so
why would it care?

Secondly, even if you were calling setAttributeNS on a level
2
namespace-aware node, setting this value does NOT change the
namespace
of the element in question.

A program which uses DOM for a namespace-aware application
should not,
in the first place, rely on xmlns attributes to determine
the namespace
of an element. That is the function of the corresponding DOM
node
functions that get the namespace URI. Setting xmlns through
the API does
not alter what is returned by those functions and does not
change the
namespace with which it will be serialized.

When the document is serialized or normalized in a
namespace-aware
fashion the xmlns attributes may be preserved, where
possible, but may
be modified as required or as desired by the implementation
to properly
represent the actual namespace.  Thus, the xmlns attributes
might be
said to contain no reliably-useful information within the
DOM beyond a
preferred set of namespace declarations, which will be
modified as
required, to represent the actual namespaces of the DOM
nodes during
serialization or normalization.

Ray Whitmer

2007/8/6, keshlamus.ibm.com <keshlamus.ibm.com>:
>
>
> >So that means you can change the default namespace
on the fly, and of
>  >all children that depend on it,
>
>  No. First off, as noted, you shouldn't be using
setAttribute() at all these
> days;

I'm not asking this from a developer point of view, but from
an DOM
implementor point of view, which must cover ALL cases.


> switch to setAttributeNS. Ideally we should have
deprecated the
> non-namespace-aware methods, but the W3C has no
deprecation mechanism and we
> wanted to preserve them for backward compatability with
DOM Level 1
> applications which would require something like
"conditional deprecation".

setAttribute it needed for non-namespace aware documents.

>
>  Second, since every element and attribute node carries
its own namespace
> information, even correctly changing/removing/adding a
namespace declaration
> has no effect on the other nodes; what it does mean is
that when you
> serialize the document back out to XML the serializer
may have to introduce
> other declarations to preserve these semantics, as
described in DOM Level
> 3's discussions of namespace normalization.
>
>  ______________________________________
>  "... Three things see no end: A loop with exit
code done wrong,
>  A semaphore untested, And the change that comes along.
..."
>  -- "Threes" Rev 1.1 - Duane Elms / Leslie
Fish
> (
http://www.ovff.org/pegasus/songs/threes-rev-11.html)


Ray basically answered the question. The default namespace
is NOT
bound to the xmlns attribute, in the DOM tree.It should be
used to
determine the namespace only at parse-time, else it should
be treated
as a regular custom attribute.