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


--- Ursprüngliche Nachricht ---
Von: Kasimier Buchcik <K Buchcik 4commerce de>
An: Rob Richards <rrichards ctindustries net>
Kopie: ML-libxml2 <xml gnome org>
Betreff: Re: [xml] Potential wrong usage of xmlIsID() in tree.c
Datum: Thu, 23 Feb 2006 17:48:20 +0100


On Thu, 2006-02-23 at 11:08 -0500, Rob Richards wrote:

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.

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.



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