Re: [xml] xmlCopyNode that doesn't copy a namespace?

[cazic gmx net]

Hi,

> Von: Theodore H.Smith <delete elfdata com>
> Datum: Sun, 1 Jan 2006 17:09:10 +0000
> 
> On 1 Jan 2006, at 11:30, Daniel Veillard wrote:
> 
> > On Fri, Dec 30, 2005 at 03:10:08PM +0000, Theodore H. Smith wrote:

[... snip, some RTFM wrt XPath stuff ;-) ...]

> >>
> >> So, I got this problem with xmlCopyNode, it's putting a namespace

Not a "namespace" is added but a "namespace declaration attribute"
(in DOM terms), or "namespace node" (in XPath terms).

> >> into the XML, when I don't actually want one there.
> >
> >   You copy a namespaced element node you gate a namespaced element  
> > node
> > the namespace is as important as the element name in a processor  
> > conformant
> > to XML namespace. You're asking to create a different element, not  
> > a copy !
> 
> Except that it is a copy, because it's going into a document with the  
> same name space.

To avoid a potential misunderstanding: I think Theodore is talking
about the additional namespace declaration attribute. This ns-decl was
added by xmlCopyNode() to avoid stale ns references. I don't think he
wants to change the namespace of the nodes.

This is a well known issue, and I know only of the lengthy workaround
that I posted a few mails up this thread.

If one has already a parent node handy, where the copied branch can
be added to, then a public version xmlStaticCopyNode() would be
perfect to avoid creation of additional ns-decls, since the
ns-decl would be found in the ancestor-or-self axis of @parent.

So I'm just repeating my question in case it went out of focus:
Does anyone see problems wrt adding a public wrapper for
xmlStaticCopyNode() which also takes a @parent argument?

Alternatively we could start implementing an xmlDOMWrapCopyNode()
function, which does everything we ever wanted ;-) and Theodore
would test it, right?

Regards,

Kasimier