Hi, On Fri, 2006-02-24 at 07:05 -0500, Rob Richards wrote: > Kasimier Buchcik wrote: > > [...] > > > > OK. Now that I have disgusted you with the narrow entry point: can we > > already foresee which additional xmlDOMWrapXXX functions we need? > > I think it would be good for Daniel to see what additional functions > > we talk about. > > > > For me the following functions come currently into consideration: > > 1) an add-child-node function > > 2) a create-attribute-node function > > 3) an add-attribute-node-to-elem function > > 4) a set-attribute-on-elem function > > Maybe 3) and 4) could be combined into one function. > > > I rather take the worse case scenario, so for now I wouldn't combine 3 > and 4. It might be possible, though I think it would be a bit ugly. The > two should be able to share a good amount of code though. I assume that > functions like 2, 3 and 4 are dual purpose and handle the NS cases as
Yes. > well. I think those might be the only ones needed. > Working on this functionality the xmlDOMWrapCtxtPtr is also going to > need to be built out. > > Rob OK. I started with an explicit prototype for xmlDOMWrapSetAttrNode() to see what mechanisms the whole thing would need. I noticed that in the case an attr is replaced by the new attr, we would need to call xmlDOMWrapRemoveNode() inside that function to remove the attr, in order to keep the DOM semantics intact. I dunno yet how we will put that mechanism into the internal code base. My intention is now just try to implement some prototypes explicitely, i.e., without trying to reuse the code base, then send it to the list for discussion, then maybe commit and then we still can try to eliminate redundant code and make the code base more flexible. Is this OK with you all? Regards, Kasimier _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
