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

On Sat, Oct 04, 2003 at 11:26:28AM +0200, Mickautsch, Alfred wrote:
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
        - share code
    - less APIs entry points
I find this idea very attractive. You could go even further and give the xmlTextReader a callback function, 
say xmlGetNextElement, used internally by xmlTextReaderRead so that one can, just by using another 
xmlGetNextElement, process virtually any kind of input data (XML/HTML files, DOM trees, config files, 
in-memory structured data,...).

  Right, this makes some sense too, this actually gets really close
to the C# interfaces if I understand correctly.
  An xmlWalker would then be a structure exposing a set of callbacks to do
NextElement/PrevElement/... Kind of low level driver access to data, and
the xmlTextReader offering a standard API on top of it.
  Maybe the existing code should be removed if we plan to go this way.
Shuffling APIs is okay during the beta phase but once 2.6.0 is released,
I must garantee API/ABI stability. Extending the base xmlTextReader to
be able to process random data is an interesting idea but might take
a bit of time to do right. I'm rather busy with other things planned
for 2.6.0 (the TODO list is simply scary !) so if you (and Bjorn and others)
want to work on it, fine, but I can't really focuse on that right now.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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