Hi, On Thu, 2005-05-19 at 12:43 -0400, Rob Richards wrote: > Kasimier Buchcik wrote: > > >Simple, but not intended. Additionally not correct, since the axis from > >the anchor element to the referenced node must not shadow the added > >ns-prefix. > > > >With raising an error is this case, adoption wouldn't work on > >attribute- and fragment-nodes. Maybe for fragment-nodes we could > >anchor the ns-decls on the fragment-node itself. > > > >However, we could add an option to let it work as you describe; although > >I don't see the point in writing an adopt function that does not support > >single attribute nodes. > >Maybe Rob Richards and Martijn Faassen could give some feedback about > >the way we should go here - after all I see it as a "help-the-wrapper" > >function. > > > > > To make sure I am following this correctly as these messages are getting > damn long: > The problem is what to do if node is not an element and no parent is > passed in, correct?
Yes, plus, if, and where we should and re-create ns-declarations for stale ns-references. > For an element, xmlReconciliateNs can be used after its set to the new > document. 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. > 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? > For fragments, the process should be done the same way. The namespace > CANT be declared on the fragment node. 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. > >Yeah might be good, although I'd like to have an optimised version at > >the end. We should consider not only splitting the code, but to > >fork to different handlers: one if @node is an element or > >fragment, one if it's an attribute, and a third otherwise. We need > >that complexity only for a branch of element nodes. > > > > > I agree about breaking it up too, though not sure what you mean about > forking. It is only going to get more complex as it still needs to > handle the entity refs, IDs, etc.. Well, it gets as complex as it needs to be. Currently we have not come to a conclusion which namespace-way to go, so the code might get more simple if we remove options or decide to go a more simple way. The result should not be affected by a "too-complex" argument (personally I don't understand why you call it complex). With "forking" I meant: just create a specialized function for simple cases, which could either be exposed to the API as well or called from the main adopt-function. Thanks for the comments! It's good not to have to decide those things alone! Regards, Kasimier _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
