Re: [xml] redicting parts of trees

[cazic gmx net]

Hi,

> Von: cazic gmx net
> Datum: Sun, 15 May 2005 14:37:00 +0200 (MEST)
> > 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.

[...]

> 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

Another possibility for the "unsafe" version would be to reactivate the
"oldNs" field of xmlDoc to anchor the not-in-scope namespace declarations
temporarily. This, together with a reconciliation prior to intersion, would
avoid creation of possibly redundant declarations and stale references. All
this is seen from a DOM wrapper perspective, where there's always a doc-node
available to anchor such things; so, maybe, the function should get a name
that clearly identifies it as being targeted for wrapper implementations.

[...]

Regards,

Kasimier