Hi, On Thu, 2005-05-19 at 09:03 -0400, Daniel Veillard wrote: > On Thu, May 19, 2005 at 01:27:22PM +0200, Kasimier Buchcik wrote: > > Hi, > > > > On Mon, 2005-05-16 at 18:12 +0200, [EMAIL PROTECTED] wrote: > > > Hi, > > > > Time for a next step. > > I attached the current sketch of an adopting mechanism. It's not > > tested - just compiles. > > didn't reviewed the code yet. Just a first step. > > > If an appropriate ns-decl was not found, it will declare a new namespace > > on: > > > > - if @parent != NULL, and @parent has an element node in the > > ancestor-or-self axis, then on @parent's top-most element node. > > - if @parent == NULL, then on the "oldNs" field of the destination > > document-node. This is important if @node is an attribute node. > > Hum, that's a problem. oldNs is not serializable, so you would end up > with document broken when serialized because they use undeclared namespaces.
Yes, this is intended. Some words about it's usage: if @parent is not given, @node needs to be reconciliated with a yet-to-write corresponding function, prior to serialisation or linking to a tree. If used by DOM wrappers, @parent is not given. Think of it as a _safe_ unlink function, which assures that ns references are not stale. The already mentioned option to anchor on @node itself, if possible, could disable the use of "oldNs". > I undertsnad it works for you special case, but the only reliable behaviour In my case we will map the ns references to intern wrapper xmlNs entries. We won't use any of the reconciliation stuff. Anchoring on "oldNs" is supposed to help wrappers which do not handle ns-references by themselves. > is to add it to the node itself if it's an element and raise an error Hmm, the "only reliable behaviour"... except for the described "oldNs" mechanism, do you already see any problems with anchoring the ns-decls on @parents top-element? > otherwise. In your special case, just check nsDef of the node before and > after > the operation is done, should be quite simple. 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. > > - Whether to user @parent's top-most element node as the anchor for new > > ns-decls, or @node's nearest element node could be set per option as > > well. It's not in yet. [...] > This is very complex code. Maybe it's unavoidable considering the > huge amount of work needed at each step. I wonder if splitting the function > in more digestible chuncks like one for processing Element, one for Attributes > and the loop wouldn't be easier to maintain. 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. Hope you'll find some time to revise the parts in it. Ah, and have a look at the dict stuff, is it OK now? Regards, Kasimier _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
