Hi,
On Thu, 2006-02-23 at 11:08 -0500, Rob Richards wrote:
> Daniel Veillard wrote:
>
> >On Thu, Feb 23, 2006 at 04:05:21PM +0100, Kasimier Buchcik wrote:
> >
> >
> >>>>Daniel, could we have that flag field on xmlDoc?
> >>>>
> >>>>
> >>> Explain clearly the semantic of it. A priori I'm not too fond of it
> >>>if we start having different data structure based on what is using the
> >>>library we just make debugging on bug reports near impossible.
> >>>
> >>>Daniel
> >>>
> >>>
> >>Such a flag would enable/disable the attribute creation/addition
> >>functions to perform an automatic ID-detection based on a DTD.
> >>
> >>I have thought about what we already have for using DOM on top
> >>of Libxml2.
> >>
> >>Proposal:
> >>We could integrate the needed ID semantics for DOM
> >>into: xmlDOMWrapRemoveNode(), xmlDOMWrapAdoptNode() and
> >>xmlDOMWrapCloneNode().
> >>What we are missing in this set of DOM functions is a
> >>xmlDOMWrapAddNode() function, which would implement the desired ID
> >>handling - based on the given options.
> >>
> >>This way we wouldn't need any additional settings on the xmlDoc - just
> >>inside the wrapper itself. A tiny beautiful island, full of DOM.
> >>
> >>
> >
> > If you really need to add a new function to the API then okay,
> >it's still way better than different behaviour based on a flag somewhere.
> >
> >Daniel
> >
> >
> I had thought about this as well but my concern was the need for new
> functionality each time a problem is found. Off the top of my head, does
> this mean there would be functions for insertBefore and setAttribute
> specific to DOM as well?
Just an idea:
If we want to avoid to many entry-points for the API, and still want
to have the chance to extend the functionalify in the future, then
what about a multi-purpose entry-point, which is adjusted by the
settings of a context:
Example:
struct _xmlDOMWrapSomeNameCtxt {
void * _private;
int type;
int mode; /* What shall be done (e.g. type of node to create,
axis: insertBefore, etc.) */
xmlNodePtr ctxtNode; /* The context node (e.g. the parent
node of an attr) */
xmlNodePtr node; /* The node to be added if existent. */
xmlNodePtr *addedNode; /* The successfully created/added node */
xmlNodePtr *removedNode; /* The removed node if any */
xmlNsPtr ns; /* The namespace struct of the to-be-added node. */
const xmlChar *name; /* The name of the to-be-added node if not
existent yet. */
};
int xmlDOMWrapSomeName(xmlDOMWrapSomeNameCtxtPtr ctxt);
I have no problem with creating such a context once for every Document
wrapper to be used for creation of nodes and addition of nodes.
If the DOM thingy inside Libxml2 is just an island of convenience for
the DOM wrappers out there, then we should not burden it with
entry-points, but just take care that we adjust the process we want to
be done on our side in a context and then push it into such a
xmlDOMWrapSomeName() Libxml2 function.
> I leaned towards the flag approach as it allowed for the re-use of
> existing functionality with some modification. My take on the flags
> approach was that the library would have its set of defaults it used for
> behavior. If flags were modified by a developer then they should know
> what they are doing and handle/resolve any bugs found. It would also
> allow additional flags to be defined that possibly could be used in the
> event of future scenarios not yet run into. It's not that I'm against
> adding the DOM functionality, I just worry that as we push the envelope
> and specs and technologies continue to evolve, we may end up back at
> this same point again due to some different issue and have to start this
> process all over again. My preference would be to not have to always
> create new functionality if it is possible to re-use existing to some
> degree.
>
> If the decision is to just create specific DOM functionality, would it
> make sense to move it all to its own file? The tree.c file is already
> quite large to sort through everything imo.
>
> Rob
I think that moving to an own file would be good. We've done that with
the functions in xmlstring.c as well, IIRC.
Regards,
Kasimier
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
