On Thu, Feb 23, 2006 at 09:49:04PM +0100, [EMAIL PROTECTED] wrote: > Thinking this over again, plus taking into account what you said about > reusing the code in tree.c, I now think that the DOM-wrapper functions > should better stay in tree.c. An other Idea: what about extending the > arguments of the "internal" functions like you did for xmlCopyPropInternal() > (dunno exactly its name, don't have the code at hand) to take additional > options we need for DOM processing? This way, the normal tree functions > would work their default way and we could add semantics for DOM. So, > together with a narrow entry point like the > xmlDOMWrapDoWhateverIWantWithTheContext(xmlDOMWrapMagicCtxtPtr ctxt) > function, we could all have what we want: a flexible and reusable internal > code base, and two flavours of APIs with different semantics on top; no > special flags on docs; no additional big DOM API inside Libxml2.
Fine by me too, more in line with the existing code. The possibility to still be able to configure DOM specific entry point out would be a plus (i.e. --with-tree but --without-dom). Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
