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

[cazic gmx net]

Hi,

> --- 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
>
> Hi,
>
> 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 
> > 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.

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.

Regards,

Kasimier