Re: [xml] Potential wrong usage of xmlIsID() in tree.c


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.


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.

We could integrate the needed ID semantics for DOM
into: xmlDOMWrapRemoveNode(), xmlDOMWrapAdoptNode() and
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.


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:


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 

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.


I think that moving to an own file would be good. We've done that with
the functions in xmlstring.c as well, IIRC.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]