Hi, > Von: Theodore H.Smith <[EMAIL PROTECTED]> > 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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
