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

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?

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.


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