Re: [xml] redicting parts of trees

[cazic gmx net]

Hi,

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

I attached a first sketch for an adopt function. It tries the "oldNs"
approach. It does not unlink the brach yet; I don't know if it should, or
rather expect the branch to be unlinked already. The function is not tested,
so just comments on its semantics please ;-)

I have the feeling that someone might object an addition to the code-base,
which clearly leaves room for handling namespaces differently. So maybe this
all ends up in a intermediate C layer for me; there won't be room for a "DOM
wrapper helper" C file, will it?

Regards,

Kasimier