Re: [xml] redicting parts of trees

[Rob Richards <rrichards ctindustries net>]

Kasimier Buchcik wrote:

> Re-creating ns-declarations for every stale reference, yes. As far as I
> understood it well, Daniel wanted to have the reconciliation being
> performed on-the-fly. If we decide to go xmlReconciliateNs's way, then
> we can get rid of that code part and call xmlReconciliateNs; although
> that will we 2 tree traversals then.
>  
Right really wasnt thinking of the element adoption in my response so 
had just thrown that out there.
On-the-fly would be best if possible.

>  
>
> > For attributes, wouldn't these be considered as being in document scope? 
> > So the namespace could be declared on the document element and things 
> > reconciled if/when it gets appended to an element. If the document 
> > doesnt have a document element then issue error.
> >    
>
> Yes, we could do it this way as well, although, to me it seems a bit to
> unpredictable to fail if there's no document-element, and not otherwise.
>
> The mechanism would be the same as declare it on "oldNs" of the
> document, the _only_ difference being that it would end up in the
> serialized result; should we not consider auto-adding as less
> ns-declarations as possible?
>  
>
> I's not about declaring, not about _storing_. It could be _stored_ on
> the attribute itself if there was a field for it; as it could be
> stored an the xmlDoc as well.
>  
basically was referring to the same thing. Dont think doing anything 
like this to a fragment is a good idea.

Thinking about this more, I tend to start leaning towards no lone 
Attribute adoption and issuing an error for this case. The 
implementation of handling lone attributes with namespaces is going to 
vary. To make use of this new adopt function could result in a lot of 
code re-write, while writing custom code for adopting a single attribute 
is not that much work. In terms of DOM, handling the namespace will be 
similar to how it implemented its createAttributeNS method.

For a fragment, store it directly on the elements. Attributes directly 
are not valid for fragments so no problem there. I'd rather have the 
serialized document be more verbose (i.e. possibly redundant namespaces) 
and safe - as it doesnt break anything and works in all cases - than 
having to try to juggle them all when finally appending the adopted 
subtree. This would then at least be inline with using xmlNewNs which 
would probably the way most DOM implementations use in their 
createElementNS method. Makes appending the nodes much easier rather 
than having to guess how the element was created to figure out if 
anything special needs to be done to handle their namespaces.

Worst case for an element, if the xmlReconciliateNs semantics of 
handling namespaces is not used, is to allow an an argument to disable 
all namespace handling so that  xmlReconciliateNs can just be called 
after its done.

Rob