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

[Rob Richards <rrichards ctindustries net>]

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?

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