Re: [xml] redicting parts of trees

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]