Hi, > Von: [EMAIL PROTECTED] > Datum: Sun, 15 May 2005 20:35:47 +0200 (MEST) > > Von: [EMAIL PROTECTED] > > Datum: Sun, 15 May 2005 14:37:00 +0200 (MEST) > > > Von: Daniel Veillard <[EMAIL PROTECTED]> > > > 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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
