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

[Daniel Veillard <veillard redhat com>]

On Thu, Feb 23, 2006 at 05:48:20PM +0100, Kasimier Buchcik wrote:
> 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:

  Urgh no... it makes code and API ugly and cryptic.

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

  yes, this may make sense, this could also be configured out. I like this
but try to not duplicate too much code. The resulting code size does matter
both from a memory runtime standpoint and from a maintainance one.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/