Re: [xml] redicting parts of trees

[cazic gmx net]

Hi,

> Von: Daniel Veillard <veillard redhat com>
> Datum: Sun, 15 May 2005 06:53:34 -0400
>
> On Sun, May 15, 2005 at 12:59:54AM +0200, Martijn Faassen wrote:

[...]

>
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Document3-adoptNode

[...]

>   Hum, the DOM3 function doesn't help us much either from a namespace
> point of
> view, it only gives a Document target, not a node target, so namespaces
> fixup can't be done with just that API. Well smart namespaces fixups can't
> be done, but there is still the possibility of adding all inscope
> namespaces
> on the node being adopted. Maybe the principle of least surprise rules
> here
> and it's better to make a more generic (in the sense you can then put the
> node anywhere in the document) and more standard API like that one.

We are in need of an adopting mechanism for our Delphi DOM wrapper as well.
I started an initial non-recursive implementation on the C side, for I hope
that doing this you will less object a candy I want to add to it, which I
wanted to have for a long time.
Some background: we somehow abuse the philosophy of how Libxml2 manages
namespace bindings, in the way that we remap all references to namespace
declaration nodes originally in the tree, to declarations handled globally
in our document wrapper. So the original declarations still are in the
document tree, but they are no more referenced. Prior to serialization a
namespace normalization mechanism performed. This all makes working with
Libxml2 more DOM conformant; additionally it makes node copy operations much
easier for us: if copying or unlinking nodes, we don't have to worry about
namespace references being not in scope; when inserting, we need no
reconciliation. This is a big plus especially when dealing with single
attribute nodes, which cannot carry a declaration, thus being dependant on
the assigned declaration to be still existent in the tree at the time of
insertion.
So the candy would be to give such an adopt function an extra context
argument, which would hold namespace acquiring callback functions or even
just a list of namespaces to pick from or add to. So if people need to use
custom namespace handling, they provide such a context, if not they pass
NULL and get the standard behaviour.

Maybe we should think about an option to the standard behaviour as well: 

- Safe method: reconciliate namespaces (with the brach-top
  as the anchor for new namespaces) at time of adopting;
  - this would not be supported for single attribute nodes
  - this could lead to many redundant namespace declarations

- Unsafe method: don't reconciliate; the user will manually reconciliate
  after he inserts the node

Additionally I would love to write an optimized copy function, with the same
namespace semantics.

Can we go this way?

Regards,

Kasimier