Re: [xml] redicting parts of trees

[Daniel Veillard <veillard redhat com>]

On Sun, May 15, 2005 at 12:59:54AM +0200, Martijn Faassen wrote:
> Martijn Faassen wrote:
> > Daniel Veillard wrote:
> [snip]
> > > I think that if we add this then we should try to match the existing
> > > semantic of those operation in PHP for example.
> >
> > Does PHP implement this operation on top of libxml2? We might also want
> > to consider the W3C importNode semantic, though I doubt it actually says
> > much of use for us here...
>
> Coming back to this myself:
>
> I just checked the dom module of PHP5, and found the implementation of 
> what looks to be importNode. Unfortunately it doesn't do what I want, as 
> it merely seems to use xmlDocCopyNode, creating a new copy of the node, 
> instead of actually moving the existing node. PHP 5's semantic in this 
> is compatible with the behavior of importNode as in the W3C DOM, which 
> defines importNode like this:
>
>   Imports a node from another document to this document, without
> altering or removing the source node from the original document; this
> method creates a new copy of the source node.

  Argh ... Well xmlCopyNode is safe in that they don't have to deal with
all the changes. But it's unfortunately slow (I realized that parsing a
serialization is faster than copying the equivalent preparsed tree :-\ )

> the semantic that we're talking about here is to adopt a node from 
> another document. The W3C DOM level 3 does provide an operation for 
> this, on the Document interface:
>
> adoptNode introduced in DOM Level 3
>
>     Attempts to adopt a node from another document to this document. If 
>  supported, it changes the ownerDocument of the source node, its 
> children, as well as the attached attribute nodes if there are any. If 
> the source node has a parent it is first removed from the child list of 
> its parent. This effectively allows moving a subtree from one document 
> to another (unlike importNode() which create a copy of the source node 
> instead of moving it).
>
> More info:
>
> http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Document3-adoptNode
>
> My hopes went up for a minute when I grepped PHP's implementation of the 
> DOm and found it did have a reference to adoptNode, but I found this:
>
> /* {{{ proto DOMNode dom_document_adopt_node(DOMNode source);
> URL: 
> http://www.w3.org/TR/2003/WD-DOM-Level-3-Core-20030226/DOM3-Core.html#core-Document3-adoptNode
> Since: DOM Level 3
> */
> PHP_FUNCTION(dom_document_adopt_node)
> {
>  DOM_NOT_IMPLEMENTED();
> }
> /* }}} end dom_document_adopt_node */
>
> So that doesn't help us very much here. :)

  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.
  
Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/