Re: WG: [xml] WG: Document traversing interface for libxml2

[Daniel Veillard <veillard redhat com>]

On Fri, Oct 03, 2003 at 03:30:24PM +0200, Mickautsch, Alfred wrote:
> Thank you Bjorn,
>
> since I just sent a patch for the original to the list, here is your version with the patch I just sent.

  Okay integrating it, I made the following changes:
    - passed both files though dos2unix to remove the CR/LF
      into LF only
    - included tree.h xmlversion.h from xmldwalk.h
    - kept xmlDocWalker structure private in xmldwalk.c
    - reformatting the header to use the new export conventions
    - I wonder how many of the function returning xmlChar *
      should actually not make a string allocation but return a
      const xmlChar * . Reusing the document dictionnary or 
      building a new one for the reader if it doesn't exist should
      avoid mallocing/freeing new strings constantly while looking for
      data in the tree. To me it's a MUSTFIX before releasing 2.6.0
      prime candidate are functions like xmlDocWalkerName
    - #define IN_LIBXML #include "libxml.h" standard libxml2 C module
      startup
    - made the code module conditional to LIBXML_WALKER_ENABLED
    - added a configuration option --with-walker

The size once compiled is a bit less than 4KB, and considering how
it may help people who are often lost walking the DOM tree, I think
it's well worth adding it by default.
The only points left are:
    - check what part of the api should really return const xmlChar *
    - is there anything needed to work on HTML documents, I don't think
      so, an htmlDocPtr is an xmlDocPtr so this should work
    - integrate the walker at the xmllint level and make regression
      tests for it, basically --walker --debug should output the same
      thing as --stream --debugand that should be fairly easy to verify,
      actually this would improve the test for the reader.
    - documentation, possibly as an extension to the existing xmlReader
      one
    - integration in the Windows (or other platform specific) makefiles

I still have a fundamental question left which is:
   - shouldn't it be better from an API and implementation point of view
     to instead make the xmlDocWalker a "subclass" of the xmlReader,
     basically creating an xmlTextReader from an xmlDocPtr, adding the 
     options to go forward and backward in that case and reuse most of
     the code from the xmlTextReader to reimplement the xmlDocWalker
     in just a slightly different way
     pros:
        - share code
        - less APIs entry points
     cons:
        - more complex implementation
        - the code ain't that big and this allows to configure the
          walker and/or the reader independantly.
        - some of the xmlTextReader API problems about const xmlChar *
          can be fixed in xmlDocWalker without ABI backward compatibility
          problems

It seems to me that the cons wins a bit over the pros so
that will probably make into 2.6.0 . I commited the current code
in CVS.

   thanks a lot !

Daniel

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