Re: [xml] libxml3 Tree API

["Hundiak, Arthur" <ahundiak ingr com>]

If I understand correctly, then an abstract tree api is exactly what we need.  The existing tree is fantastic 
but is overkill for my applications.  But I need to use it for xpath/xslt.

I know there would be an overhead to using an abstract interface since you could no longer access member 
variables directly, on the other hand not needing to access member variables directly means the structures 
can be taken private and changed without breaking things.

I'd be very willing to assist in this effort.

----------------------------------------------------
Date: Thu, 18 Apr 2002 03:27:18 -0400
From: Daniel Veillard <veillard redhat com>
To: Peter Jacobi <pj walter-graphtek com>
Cc: xml gnome org
Subject: Re: [xml] libxml3
Reply-To: veillard redhat com

On Thu, Apr 18, 2002 at 09:08:58AM +0200, Peter Jacobi wrote:
> > That's what the SAX interface provide. With the following document
> > fragment ...
>
> Yes, but the SAX interface gives much less functioniality than the
> tree interface. I want to have the functionality of the tree interface,
> but using an API that does no memory allocation on 
> non mutating calls.
>
> (Because, e.g.  the data may go to C++ STL to avoid double
> copy and double memory allocation)

  Okay, then a Push (at the tree level not at the input, the wording
in this field is confusing) would probably be sufficient. Would an
API building and destroying the tree by default and using callbacks
would fit the bill ? In practice it could be a parsing option 
with a (set of) callback and the parser would just call it with the
built node in its context (the retained child subtree and all the ancestors
nodes), then depending on the value returned in the callback the subtree
would either keep the nodes and its subtree, or destroy it.
  I think this would be relatively flexible, not hard to implement
nor disruptive w.r.t. the existing code base and APIs, i.e. I could
probably sneak something like this even in libxml2, either as a global
setting or specifically associated to a given parser context.

  Opinions ?

Daniel