Re: [xml] redicting parts of trees

[Kasimier Buchcik <kbuchcik 4commerce de>]

Hi,

On Tue, 2005-05-24 at 15:15 +0200, Kasimier Buchcik wrote: 
> Hi,

I would like to make a change to xmlReconciliateNs(), while fixing it.

Current behaviour/errors:
1) It does not find already existent ns-decls in @root's descendants;
   this can lead to shadowed prefixes.
2) Due to a speed-up code of xmlSearchNsByHref(), which returns
   a ns-decl even if it is not declared, but just referenced, it will
   fail to create missing ns-decls.
3) It creates missing ns-decls on @root only.
4) If creating missing ns-decls, it does not allow to reuse a prefix,
   which is already used in @tree's parent axis. This increases the
   cases, where the prefix need to be change.
   Example: For missing ns-decls in the default namespace, the prefix 
   will be changed to "default1", "default2", etc.

New behaviour:
1) It will attach ns-references to the nearest ancestor ns-decl with the
   same ns-name; this includes @root's descendant axis.
2) It will not use ns-references while searching for ns-decls.

Now the most important change:
3) It will create missing ns-decls on the nearest ancestor-or-self
   of a node which references a missing ns-decl.

Arguments for 3):

It will be more conforming to W3C's ns-normalisation algorithm, which
creates missing ns-decls where first needed.

The following tries to advocate 3) from the view of DOM-wrappers:

DOM-wrappers should not create ns-decls automatically, so a
ns-normalization is only performed per DOM-API call. I.e. it would be
wrong to magically auto-create a ns-decl on any added element-node on
the node itself.
Example (Delphi code):

elem := doc.createElementNS('', 'a1');
doc.appendChild(elem);
for i := 1 to 3 do begin
  elem := doc.createElementNS('urn:test:foo', 'foo:a2');
  doc.documentElement.appendChild(elem);
end;

should not result in...

<a1>
  <foo:a2 xmlns:foo="urn:test:foo"/>
  <foo:a2 xmlns:foo="urn:test:foo"/>
  <foo:a2 xmlns:foo="urn:test:foo"/>
</a1>

... automatically. With DOM, one still has the possibility to add a
namespace declaration attribute to avoid this:

doc.documentElement.setAttributeNS('http://www.w3.org/2000/xmlns/',
'xmlns:foo');

resulting in the following:

<a1 xmlns:foo="urn:test:foo">
  <foo:a2/>
  <foo:a2/>
  <foo:a2/>
</a1>

It seems that xmlReconciliateNs() should not be expected to be called
immediately after each change to the tree.

This being said, creating missing ns-decls on nearest ancestor-or-self
elements will have the following advantage:

Consider the following doc pieces:
<p1 xmlns="urn:test:AAA">
  <a/>
</p1>

<p1 xmlns="urn:test:BBB">
  <b/>
</p1>

Remove <a> and <b> and add them to <p2>:
<p2 xmlns="urn:test:ZZZ"/>  
  <a/> <!-- a.namespaceURI() is "urn:test:AAA", a.prefix() is NULL -->
  <b/> <!-- a.namespaceURI() is "urn:test:BBB", a.prefix() is NULL -->
</p2>

Ns-reconcile <p2>:
<p2 xmlns="urn:test:ZZZ"/>  
  <a xmlns="urn:test:AAA"/>
  <b xmlns="urn:test:BBB"/>
</p2>

So we preserve the default namespace for <a> and <b> if we create
ns-decls where needed. On the other hand, if creating new ns-decls on
<p2> only, we get:

<p2 xmlns="urn:test:ZZZ"   
    xmlns:default1="urn:test:AAA"
    xmlns:default2="urn:test:BBB"/>  
  <default1:a />
  <default2:b />
</p2>

Now consider big content of <a> and <b>, plus QNames in text content
which require the default namespace: the advantage of the default
namespace is lost, plus QNames without a prefix are in the wrong
namespace.

By the way, the DOM Document.normalizeDocument() method, which can
ns-normalize the document as well, need not to be called by the user. So
it's up to the user: if he thinks that he has placed the namespace
declaration attributes at the correct position, then he don't need to
ns-normalize; this is commonly done if the doc is big and a
ns-normalization is avoided. If he's unsure, or simply didn't care about
declaring namespaces, he'll call Document.normalizeDocument().


Any objections to change xmlReconciliateNs this way?

Greetings,

Kasimier